Inhaltsverzeichnis 1 Einleitung 1 I Moderne Methoden des Software-Engineering 3 2 OO-Softwareentwicklung mit dem Rational Unified Process Einlei

Transkript

1 INTERNE BERICHTE Carl von Ossietzky Universität Oldenburg Fachbereich Informatik Zwischenbericht der Projektgruppe Werkzeuge für Digitale Bibliotheken D. Boles, C. Haber, Volker Weber, Oliver Klein, Maik Höft, Axel Wunsch, Michael Hülsmann, Andre Rolfs, Daniel Pawlowski, Jens Eschke, Werner Willms, Michael Klein, Tobias Ottenhues, Michael Malachinski Bericht IS xx Teil B April 2000

2 Inhaltsverzeichnis 1 Einleitung 1 I Moderne Methoden des Software-Engineering 3 2 OO-Softwareentwicklung mit dem Rational Unified Process Einleitung Motivation Einordnung Rational Unified Process Erfahrungswerte der Softwareentwicklung Die Phasen von RUP Inception Elaboration Construction Transition Die Elemente des Rational Unified Process Worker Activities Artifacts Workflows Die Kern Workflows Core Process Workflows Core Supporting Workflows i

3 ii INHALTSVERZEICHNIS 3 OO-Analyse mit der UML und Use Cases Einleitung Motivation UML Aufbau Use Cases -derbeginn Analyse Akteure und die Grenzen des Systems Von Akteuren zu Use Cases Use Case Diagramme Vom Use Case zu seinen Verhaltensdiagrammen Aktivitätsdiagramme Sequenzdiagramme Kollaborationsdiagramme Zustandsdiagramme Vom Verhalten zur logischen Struktur Klassen Beziehungselemente und Klassendiagramme Subsysteme und Paketdiagramme Implementierungsdiagramme Iterative Projektplanung mit Use Cases Der Einsatz von Use Cases in der Konstruktionsphase Abschließende Anmerkungen OO-Entwurf mit Frameworks und Entwurfsmustern Einleitung Entwurfsmuster und Frameworks Aufbau des Artikels Einleitung - Entwurfsmuster Motivation

4 INHALTSVERZEICHNIS iii Definition Beispiel: Entwurf der Dokumentstruktur eines Editors Entwurfsmuster "Kompositum" "Kompositum" angewandt auf das "Dokumentstrukturproblem" Beschreibung von Entwurfsmustern Klassifikation von Entwurfsmustern Auswahl geeigneter Entwurfsmuster Suche Anwendung Frameworks - Motivation und Definition Klassifizierung von Frameworks Vorteile von Frameworks Probleme bei der Frameworkentwicklung Frameworkentwicklung Zusammenfassung - Entwurfsmuster und Frameworks OO-Programmierung mit Softwarekomponenten Einleitung Motivation Softwarekomponenten Aufbau der Ausarbeitung Softwarekomponenten Allgemeines Komponentenmodelle JavaBeans Was ist JavaBeans? Struktur einer Bean JavaBeans-API

5 iv INHALTSVERZEICHNIS 5.4 Bean-Eigenschaften Gebundene Eigenschaften Eigenschaften mit Constraints Verwendung von Eigenschaften JavaBeans in der Praxis Entwicklung von JavaBeans Anwendung von JavaBeans Werkzeuge für JavaBeans Abschließende Anmerkungen Client/Server-Programmierung mit Java Einleitung Motivation Client/Server-Architektur Aufbau des Artikels Java und Sockets Was sind Sockets? Die Kommunikationsklassen Beispielimplementierung Java-RMI Grundlagen Entwicklungszyklus Ablauf einer RMI-Applikation Java und CORBA Grundlagen Interface Definition Language (IDL) Der Ablauf eines Methodenaufrufs Corba - Entwicklungszyklus Abschließende Anmerkungen

6 INHALTSVERZEICHNIS v 7 DB-Anbindung für Internet-Informationssysteme Einführung Motivation für Datenbank-Anbindungen Die Einschränkungen des One-Way-Download Datenbanken Ein Modell einer Datenbank-Anbindung über das Internet Die klassische Datenbank-Anbindung mit CGI ASP - Active Server Pages Reichen CGI und ASP aus? ODBC und JDBC ODBC -OpenDatabase Connectivity JDBC -Java Database Connectivity Java : Applets und Servlets Java-Applets Java-Servlets Proprietäre Datenbank-Schnittstellen Was ist eine proprietäre Datenbank-Anbindung? Beispiele für proprietäre Datenbank-Anbindungen Ist eine proprietäre Datenbank-Anbindung besser als eine Selbsterstellte? Fazit II Einführung in Digitale Bibliotheken 99 8 Das Publikations- und Bibliothekswesen Einleitung Wie das flüchtige Wort festgehalten wurde Der Wandel der Bibliotheken in der Zeit Wird sich die Bibliothek weiterentwickeln?

7 vi INHALTSVERZEICHNIS 8.2 Der traditionelle Publikationsprozeß Der Produzenten-Workflow Der Distributoren-Workflow Der Konsumenten-Workflow Die Aufgaben einer Bibliothek Beschaffen und Erfassen Indexieren Recherchieren Vermitteln von Informationen Nachteile des traditionellen Bibliothekswesens Nachteile traditioneller Bibliotheken Nachteile traditionelles Publikationswesen Digitale Bibliotheken Was sind Digitale Bibliotheken Änderungen im Publikationsprozeß und den Bibliotheksaufgaben Vorteile von Digitalen Bibliotheken Vorteile im Bibliothekswesen Vorteile im Publikationsprozeß Abschließende Anmerkungen Digitale Bibliotheken im Vergleich Einleitung Allgemeines zu digitalen Bibliotheken Arten von digitalen Bibliotheken mit Beispielen Vergleichskriterien Digitale Bibliotheken Fachgesellschaften und Verlage Graue Literatur und CSTR Einbindung heterogener Informationsquellen in eine einheitliche Systemwelt Abschließende Anmerkungen

8 INHALTSVERZEICHNIS vii 10 Information Retrieval Einleitung Beispiel von IR anhand einer Literatur-Datenbank Ein Grund-Modell des IR Information Retrieval bei Texten Grundlegendes zur Freitextsuche Informatischer Ansatz Computerlinguistischer Ansatz IR-Ansätze Bewertung von Anfrage-Ergebnissen Der nicht-probabilistische Ansatz Der probabilistische Ansatz Bewertung gegenwärtiger Systeme Bewertung des Booleschen Retrieval Bewertung des Ranking-Verfahrens Bewertung des Fuzzy-Retrieval Bewertung des Vektorraummodells Ausblick auf die Zukunft Metadaten Einleitung Charakterisierung von Internetdokumenten Katalogisierung in herkömmlichen Bibliotheken Kriterien zur Beschreibung von digitalen Dokumenten Metadaten zur Beschreibung von Internetdokumenten Metadaten -was ist das? Funktionen von Metadaten Vorteile von Metadaten Typen von Metadaten

9 viii INHALTSVERZEICHNIS Repräsentation von Metadaten Verschiedene Metadatenformate Dublin Core Element Set (DC) Zielsetzungen Die Attribute der Dublin Core Elemente Die Elemente des Dublin Core Resource Description Framework (RDF) Was ist RDF? Das grundlegende RDF Modell Modellierung eines RDF Statements RDF und Dublin Core Abschließende Anmerkungen XML Einleitung XML in 10 Punkten Historie von XML Der Zweck von XML XML Dokumente HTML-Beispiel XML-Beispiel XML-Notation - well-formed" - gültig" DTD - Document Type Definition Was ist die DTD und wozu dient sie? EinbindunginXML DTD - Ein Beispiel DOM - Document Object Model CSS / XSL Style Sheets CSS

10 INHALTSVERZEICHNIS ix XSL Interessantes für Java-Programmierer Anwendungsbeispiel: MathML Der Zweck von MathML Ein kleines MathML-Beispiel XML &Java Was verbindet XML & Java Verarbeitungszyklus eines XML-Dokuments Java-basierte Werkzeuge für XML Beispiel: Parser zur Inhaltsverzeichnisgenerierung Abschließende Anmerkungen Elektronischer Zahlungsverkehr im Internet Einleitung Anforderungen an elektronische Zahlungsverfahren Sicherheitstechnische Grundlagen Verschlüsselungsverfahren Secret Key-Verfahren (symmetrisch) Public Key-Verfahren (asymmetrisch) Kombination aus Secret- und Public Key-Verfahren Sichere Hashfunktionen Digitale Signatur Charakteristika von Zahlungsarten Zeitpunkt der Zahlung Art der Zahlung Höhe der Zahlung Vorstellung einzelner Zahlungsverfahren SET (Secure Electronic Transaction) Ecash MilliCent Abschließende Anmerkungen

11 x INHALTSVERZEICHNIS Literatur 216

12 Abbildungsverzeichnis 2.1 Das Wasserfall-Modell Die Entwicklung Phasen und Workflows des RUP Worker,Activities and Artifacts Worker und Activities Beispiel eines Workflows Use Case Diagramm Beispiel Aktivitätsdiagramm Beispiel Entscheidungspunkte und Parallelität Darstellung eines Objekts im Sequenzdiagramm Sequenzdiagramm für den Use Case Bestellung suchen Kollaborationsdiagramm Zustandsdiagramm einer Bestellung Klassennotation und Beispiele Assoziationsbeziehung Assoziationsbeziehung Aggragationsbeziehung Kompositionsbeziehung Notation einer Komponente Notation eines Einsatzdiagramms Schema eines Entwurfsmusters xi

13 xii ABBILDUNGSVERZEICHNIS 4.2 Struktur einer Dokumentenseite Entwurfsmuster "Kompositum" Konkrete Anwendung des "Kompositums" Schema eines Frameworks und einer Applikation Frameworkentwicklung Struktur einer JavaBean Die innere Arbeitsweise einer gebundenen Eigenschaft Die Arbeitsweise einer Eigenschaft mit Constraints Die BeanBox Drag&Drop in der BeanBox Verbinden von Beans in der BeanBox Client/Server-Architektur Sockets RMI -Entwicklungszyklus CORBA - Methodenaufruf CORBA -Entwicklungszyklus Der Produzenten-Workflow Der Distributoren-Workflow Der Konsumenten-Workflow NCSTRL-Architektur NCSTRL-Regional NZDL-Architektur NZDL-Text MeDoc-Architektur UniCats-Architektur

14 ABBILDUNGSVERZEICHNIS xiii 10.1 Beispiel-Recherche zu obiger Anfrage an ein IR-System Ein Grund-Modell des Information Retrieval Teilmengen eines Anfrage-Ergebnisses Das Grund-Modell des nicht-probabilistischen Ansatzes Beispiel des Ranking-Verfahrens Beispiel des Vektorraummodells Die Struktur eines RDF Statements als gerichteter Graph Ein RDF Statement als gerichteter Graph mit analogen Bezeichnern Beispiel eines Statements als gerichteter Graph HTML-Code des Beispiels HTML-Ausgabe des Beispiel-Codes XML-Code des Beispiels Start- und End-Tag Empty-Tag Ausschnitt aus der Beispiel-DTD Baumartige Repräsentation des Beispiels automatische XML-Dokument-Umwandlung strukturelle Gemeinsamkeiten von Java und XML Verarbeitungszyklus eines XML-Dokuments grober Aufbau eines Buches Codeausschnitt: Parser zur Inhaltsverzeichnisgenerierung Prinzip der Verschlüsselung. Quelle: [DL97] Kombination von DES und RSA. Quelle: [Sto97] Übermittlung und Verifikation der Zahlungsdaten über Cybercash. Quelle:[Sto97] Erzeugung digitaler Münzen bei Ecash. Quelle: [Sto97] Bestell- und Zahlungsvorgang bei Ecash. Quelle: [Sto97]

15 Kapitel 1 Einleitung Dieser Bericht fasst die Ergebnisse zusammen, die etwa bei Halbzeit der Projektgruppe toolib (Werkzeuge für Digitale Bibliotheken) vorliegen. toolib ist eine Projektgruppe des Fachbereichs Informatik der Universität Oldenburg, die im Wintersemester 1999/2000 und im Sommersemester 2000 stattfindet. Dieser Zwischenbericht setzt sich aus zwei Teilen zusammen: ffl Teil A faßt den bisherigen Ablauf und die bisherigen Ergebnisse der Projektgruppe zusammen. ffl Teil B enthält die ausgearbeiteten Seminarvorträge aus dem ersten Abschnitt der Projektgruppe. Nach Abschluss der Projektgruppe im Sommer 2000 wird ein Endbericht erscheinen. Innerhalb der Seminarphase der Projektgruppe wurden insgesamt 12 Vorträge gehalten, die die Teilnehmer der Projektgruppe organisatorisch und inhaltlich auf die Projektgruppe vorbereiten sollten. Die schriftlichen Ausarbeitungen der Seminarvorträge werden in diesem Bericht zusammengefasst. Die Beiträge lassen sich dabei in zwei Gruppen einteilen: ffl Im Teil Moderne Methoden des Software-Engineering wurden die sechs Vorträge Objektorientierte Softwareentwicklung mit dem Rational Unified Process (Volker Weber) Objektorientierte Analyse mit der UML und Use Cases (Oliver Klein) Objektorientierter Entwurf mit Frameworks und Entwurfsmustern (Maik Höft) Objektorientierte Programmierung mit Softwarekomponenten (Axel Wunsch) Client/Server-Programmierung mit Java (Michael Hülsmann) 1

16 2 KAPITEL 1. EINLEITUNG Datenbankanbindung für Internet-Informationssysteme (Andre Rolfs) gehalten. ffl Im Teil Einführung in Digitale Bibliotheken wurden die sechs Vorträge Traditionelles und digitales Publikations- und Bibliothekswesen (Daniel Pawlowski) Digitale Bibliotheken im Vergleich (Jens Eschke) Information Retrieval (Werner Willms) Metadaten (Michael Klein) XML (Tobias Ottenhues) Elektronischer Zahlungsverkehr im Internet (Michael Malachinski) gehalten.

17 Teil I Moderne Methoden des Software-Engineering 3

18

19 Kapitel 2 Objektorientierte Softwareentwicklung mit dem Rational Unified Process Volker Weber Der Rational Unified Process ist ein objektorientierter Software-Entwicklungsprozess, der von der Firma Rational entwickelt wurde. Der Software-Entwicklungsprozess wird in vier Phasen und neun logische Aufgaben unterteilt. Er ist als ein iterativer Prozess ausgelegt, was dazu führt, dass schon in frühen Entwicklungsstadien Prototypen entwickelt sind und so Risiken und Probleme auch in frühen Stadien erkannt werden können. Der Rational Unified Process definiert Workflows in denen beschrieben wird, welche Aufgaben zu welchem Zeitpunkt durchzuführen sind. Dieser Artikel gibt eine Übersicht über die wichtigsten Eigenschaften und Elemente des Rational Unified Process. 5

20 6KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS 2.1 Einleitung Motivation Die Software-Krise in den 60'er Jahren brachte die Forderung nach ingenieurmäßigen, strukturierten und teamorientierten Software-Entwicklungs-Methoden, ohne die Software mit Ihrer heutigen Komplexität gar nicht mehr möglich währe. Es sind seitdem einige Software-Entwicklungs-Methoden vorgestellt worden. Dieser Artikel stellt die Software-Entwicklungs-Methode Rational Unified Process der Firma Rational näher vor Einordnung Eine Software-Entwicklungs-Methode beschreibt den Lebenszyklus eines Softwareprojektes/- produktes ausgehend von der Idee über den Entwicklungsprozess, die Produkt-Einführung bis zum Betrieb und der Wiederabschaffung. ffl Das Wasserfall-Modell (Abb. 2.1) beschreibt einen Entwicklungs-Zyklus, in dem die einzelnen Stufen in festgelegter Reihenfolge angeordnet sind und von oben nach unten durchlaufen werden. Software- anforderungen Systemanforderungen Analyse Entwurf Codierung Testen Betrieb Abbildung 2.1: Das Wasserfall-Modell

21 2.1. EINLEITUNG 7 ffl Objektorientierte Prozess-Modelle setzen sich in der Software-Entwicklung mehr und mehr durch. Als Alternativen zum Rational Unified Process der in diesem Artikel beschrieben wird, gibt es unter anderem die folgenden, im industriellen Einsatz befindlichen OO-Entwicklungs-Modelle: WSDDM Worldwide Solution Design and Delivery Method ist ein Methoden- Paket das von der IBM Consulting Gruppe als Beratungs-Grundlage entwickelt wurde. WSDDM basiert auf Lotus Notes, und unterstützt Projektleiter und Team-Mitarbeiter durch Tools. V-Modell Als Entwicklungsstandard für IT-System des Bundes (EStdIT) für den gesamten Bereich der Bundesverwaltung verbindlich einzusetzender Entwicklungsprozess. Das V-Modell beschreibt Aktivitäten und Produkte, die während der Entwicklung von Software durchzuführen bzw. zu erstellen sind. Es legt fest, mit welchen Methoden die Aktivitäten durchzuführen und welche Darstellungsmittel in den Ergebnissen zu verwenden sind und beschreibt welche funktionalen Eigenschaften diejenigen Software-Werkzeuge ( tools ) aufweisen müssen, die bei der Entwicklung von Software eingesetzt werden sollen. SELECT Perspective Eine Methode der Firma Select Software Tools zur Entwicklung von Client/Server Systemen. Die SELECT Perspective enthält eine Sammlung industrieller Entwicklungs-Modelle, die mit Prozeßschablonen innerhalb eines architektonischen Rahmens angewendet und angepaßt werden. AE-Modell Vom Informatik-Zentrum der Sparkassen-Organisation herausgegebenes Anwendungsentwicklungsmodell.Das AE-Modell stellt Vorgehensweisen für konventionelle Software-Projekte bereit und unterstützt deren Durchführung mit Standards und Verfahren aus der Projekt-Praxis ( Best Practices ) Rational Unified Process Der Rational Unified Process ist eine auf der UML basierende Software-Engineering- Methode der Firma Rational. Er erhebt den Anspruch, den gesamten Software-Lebenszyklus abzudecken. Im Mittelpunkt des Ansatzes stehen Use-Cases und objektorientiertes Design. Für die verschiedenen logischen Aufgaben bei der Softwareentwicklung werden Workflows definiert, die den Ablauf darstellen. Das Produkt Rational Unified Process besteht aus: ffl Einer Online Version: Einer ausführlichen Beschreibung in Form einer vollständig verlinkten Website. Tool Mentoren, die zusätzliche Hilfen zur Verwendung-/Eingliederung von weiteren Entwicklungswerkzeugen geben. Templates für alle wichtigen Prozess-Dokumente. ffl Einer Reihe von gedruckten Handbüchern.

22 8KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS 1998 Performance testing Buisiness Engineering Configuration & Change Management Rational Unified Process 5.0 Objectory UI Design Data Engineering UML Requirements College Rational Objectory Process 4.1 SQA Process UML UMT Booch Rational Objectory Process 4.0 UML Rational Approach Objectory Process 3.8 Abbildung 2.2: Die Entwicklung Der Rational Unified Process wurde während vieler Jahre entwickelt und durch die Erfahrung vieler Menschen und Firmen geprägt. Die Abbildung (Abb. 2.2) gibt einen kurzen Überblick über die Entwicklung. Der Rational Unified Process ist der direkte Nachfolger des Rational Objectory Process der aus dem Objectory Process der Schwedischen Firma Objectory AB und dem Rational Approach der Firma Rational.

23 2.2. ERFAHRUNGSWERTE DER SOFTWAREENTWICKLUNG Erfahrungswerte der Softwareentwicklung In der Softwareentwicklung haben sich Erfahrungswerte herausgebildet, die der Rational Unified Process zu unterstützen versucht: Iterative Entwicklung Die iterative Softwareentwicklung ermöglicht es, Softwaresysteme so zu entwickeln, dass von Beginn an alle Probleme benannt werden, ohne dass sofort detaillierte Lösungen bestehen müssen. Der Rational Unified Process unterstützt durch iterative Entwicklung die frühzeitige Erkennung von Risiko-Bereichen. Da jede Iteration ein ausführbares Programm hervorbringt kann, auf Benutzerrückmeldungen schon in frühen Entwicklungsstadien reagiert werden. Inkonsistenten einzelner Komponenten werden bereits in den ersten Iterationen erkannt. Manage die Anforderungen Der Rational Unified Process beschreibt, wie sich die Anforderungen erkennen, organisieren und dokumentieren lassen. Durch die Dokumentation der Anforderungen lassen sich bei Änderungen Inkonsistenzen vermeiden. Die vom Rational Unified Process verwendeten Use-Cases und Szenarien sind geeignet, die Anforderungen zu beschreiben. Benutze komponentenbasierte Architekturen Durch die Verwendung von komponentenbasierten Systemen können auch große Software-Projekte in kleinen überschaubaren Teilen entwickelt und getestet werden. Modelliere Software visuell Der Rational Unified Process zeigt, wie sich Software visuell modellieren lässt, um das Verhalten und die Struktur der Komponenten abzubilden. Durch das Modellieren mit UML, Use-Cases und Szenarien lassen sich Details verbergen und die Übersicht über das Zusammenpassen der Komponenten verbessern. Überprüfe die Software-Qualität Der Rational Unified Process unterstützt Planung, Design, Implementierung, Durchführung und Überprüfung der Tests. Dadurch wird das Einhalten der Qualitätsanforderungen erleichtert. Kontrolliere die Softwareänderungen Das Kontrollieren der Softwareänderungen zwingt zu klaren Absprachen aller beteiligten Personen. Die Änderungen bleiben klar definiert und wiederherstellbar.

24 10KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS 2.3 Die Phasen von RUP Der Rational Unified Process gliedert sich in vier Phasen (Abb. Haupt-Meilenstein als Abschluss haben. 2.3), die jeweils einen Jede dieser vier Phasen wird in einer bis mehreren Iterationen durchlaufen. Jede Iteration ist ein kompletter Entwicklungszyklus, an dessen Abschluss ein Prototyp steht. Dieser Prototyp wird mit jeder Iteration vollständiger, bis am Ende das fertige Softwareprodukt vorliegt. Abbildung 2.3: Phasen und Workflows des RUP Inception Während der Inception Phase wird das Problem analysiert und der Projektbereich eingegrenzt. Dazu müssen alle mit den System agierenden Stellen identifiziert und das Wesen dieser Interaktion beschrieben werden. Die Resultate dieser Phase sind: ffl Ein Vision-Dokument: eine Beschreibung der Anforderungen des Kernprojektes und der Schlüsseleigenschaften. ffl Ein erstes Use-Case Modell, welches die wichtigsten Use-Cases umfasst. ffl Ein erstes Projekt-Glossar, in dem die verwendeten Begriffe definiert sind. ffl Eine erste Problembeschreibung, die Umfeld, Erfolgskriterien, Marktanalyse etc. enthält.

25 2.3. DIE PHASEN VON RUP 11 ffl Eine erste Risikobeurteilung, die die Hauptrisiken beschreibt und Lösungswege skizziert. ffl Ein Projektplan, der Phasen und Iterationen darstellt. ffl Wenn notwendig ein Geschäftsmodell. ffl Einen oder mehrere Prototypen, die einen Eindruck über die geplanten Benutzungsschnittstellen liefern. Diese Phase endet mit dem Life-Circle-Objective Meilenstein. Dieser beinhaltet folgende Anforderungen: ffl Alle Beteiligten Personen haben eine gemeinsame Sicht auf Definitionen, Kosten und Zeitplan. ffl Die Anforderungen werden durch die Funktionalität der ersten Use-Cases erfüllt. ffl Es besteht ein realistischer Kosten- und Zeitplan. ffl Jeder entworfener Prototyp wurde in Tiefe und Breite erkundet. ffl Die aktuellen Aufwendungen decken sich mit den geplanten. Das Projekt kann abgebrochen werden oder muss neu überdacht werden, wenn es diesen Meilenstein nicht erfüllen kann Elaboration Der Zweck der Elaboration Phase ist, das Problem zu analysieren, eine solide architektonische Grundlage herzustellen, den Projektplan zu entwickeln und die größten Risiken zu beseitigen. Um architektonische Entscheidungen zu treffen, muss das ganze System verstanden worden sein: Den Bereich, die Hauptfunktionalität, die nicht-funktionalen Anforderungen, wie z.b. die Anforderungen bezüglich der Performance. Am Ende dieser Phase steht die Entscheidung, ob das Projekt realisierbar ist und ob in die nächsten beiden kosten-aufwendigen Phasen eingetreten werden kann. Die Resultate dieser Phase sind: ffl Ein mindestens zu 80% vollständiges Use-Case Modell, in dem alle Use-Cases und Akteure identifiziert sind und die meisten Use-Case Beschreibungen entwickelt wurden. ffl Ergänzende Anforderungen die die nicht-funktionalen und alle sonstigen Anforderungen, die nicht durch die Use-Cases spezifiziert werden, umfassen. ffl Eine Beschreibung der Software-Architektur. ffl Ein ausführbarer architektonischer Prototyp.

26 12KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS ffl Ein revidierter Projektplan und eine revidierte Risikobeurteilung. ffl Ein Entwicklungsplan für das gesamte Projekt, der die Iterationen und die Auswertungskriterien für die Iterationen zeigt. ffl Ein aktualisierter Entwicklungsplan, der den zu verwendenden Prozess spezifiziert. ffl Und optional ein erstes Benutzer-Handbuch. Diese Phase endet mit dem Life-Circle-Architecture Meilenstein. Dieser beinhaltet folgende Anforderungen: ffl Die Sicht des Produktes ist stabil. ffl Die Architektur ist stabil. ffl Der Prototyp zeigt, dass die Hauptrisiken gefunden und behoben wurden. ffl Der Plan für die Construction Phase ist ausreichend detailliert und durch realistische Schätzungen gesichert. ffl Alle Beteiligten sind der Auffassung, dass die aktuelle Vision durch die Durchführung des aktuellen Plans erreicht werden kann. ffl Der Vergleich zwischen aktuellen und geplanten Aufwendungen ist vertretbar. Das Projekt kann beendet werden oder muss neu überdacht werden, wenn es diesen Meilenstein nicht erfüllen kann Construction Während der Construction Phase werden die restlichen Komponenten und Produkt- Eigenschaften entwickelt und integriert. Das gesamte Produkt wird ausgiebig getestet. Die Resultate dieser Phase sind: ffl Das Softwareprodukt. ffl Ein Benutzer-Handbuch. ffl Eine Release Beschreibung. Diese Phase endet mit dem Initial Operational Capability Meilenstein. Dieser beinhaltet folgende Anforderungen: ffl Das Produkt-Release ist stabil genug, um es an die Benutzer auszuliefern. ffl Alle Beteiligten sind zu der Auslieferung des Produktes bereit. ffl Der Vergleich zwischen aktuellen und geplanten Aufwendungen ist noch vertretbar. Der Übergang in die Transition-Phase muss hinausgeschoben werden, wenn dieser Meilenstein nicht passiert werden kann.

27 2.3. DIE PHASEN VON RUP Transition Der Zweck der Transition Phase ist, das Softwareprodukt bei den Benutzern zu installieren und es einzuführen. Wenn das Produkt beim Benutzer eingeführt wird, entstehen normalerweise Probleme, die durch eine neues Release behoben werden müssen. Es müssen eventuell noch Eigenschaften fertig-gestellt werden, die heraus-geschoben wurden. Am Ende der Transition Phase steht der vierte Haupt-Meilenstein, der Product Release Meilenstein, dieser definiert folgende Anforderungen: ffl Der Benutzer ist zufrieden. ffl Die tatsächlichen Aufwendungen an Ressourcen sind gegenüber den geplanten noch vertretbar.

28 14KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS 2.4 Die Elemente des Rational Unified Process Der Rational Unified Process beschreibt ffl wer (Worker) ffl wann (Workflow) ffl was (Artifact) ffl wie (Activity) tut. Dazu werden die Elemente Worker, Activities, Artifacts und Workflow benutzt. Abbildung 2.4: Worker,Activities and Artifacts Worker Ein Worker definiert die Aufgaben und die Verantwortlichkeiten einer Einzelperson oder eines Teams. Ein Worker steht dabei für die Rolle, die im Prozess zu erledigen ist. Jede Einzelperson kann dabei mehrere Rollen erfüllen, und jede Rolle kann auch von verschiedenen Personen erfüllt werden. Beispiele für Worker sind: ffl Project Manager ffl System Analyst ffl Design Reviewer ffl Performance Tester ffl...

29 2.4. DIE ELEMENTE DES RATIONAL UNIFIED PROCESS Activities Abbildung 2.5: Worker und Activities Eine Activity eines speziellen Workers ist eine Aufgabeneinheit, die in dieser Rolle ausgeführt werden soll. Die Activity hat ein klares Ziel, normalerweise das Bearbeiten eines Artifacts. Jede Activity ist einem speziellem Worker zugeordnet. Jede Activity soll als ein Element der Planung und des Fortschritts verwendbar sein. Beispiele für Activities sind: ffl Das Planen einer Iteration ( Worker: Project Manager). ffl Das Identifizieren von Use-Cases und Akteuren ( Worker: System Analyst). ffl Das Durchführen von Performance Tests ( Worker: Performance Tester). ffl Artifacts Ein Artifact ist ein Stück Information das durch den Prozess erstellt, verändert oder benutzt wird. Artifacte sind die greifbaren Produkte, die während des Prozesses entstehen und bis zum fertigen Softwareprodukt bearbeitet und benutzt werden. Artifacte sind die Eingaben und die Resultate der Activities, die durch Worker durchgeführt werden. Beispiele für Artifacts sind: ffl Ein Modell, z.b. Use-Case Modell, Design Modell ffl Ein Element eines Modells, z.b. eine Klasse, ein Use-Case,... ffl Ein Dokument, z.b. Benutzer-Handbuch, Software Architektur Dokument.

30 16KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS ffl Quellcode. ffl Workflows Ein Workflow (Abb. 2.6) setzt Worker, Artifacts, und Activities in eine Beziehung, die beschreibt in welcher Reihenfolge die Aktivitäten von welchem Worker angewendet werden sollen, um ein bestimmtes Resultat zu erzielen. Abbildung 2.6: Beispiel eines Workflows

31 2.5. DIE KERN WORKFLOWS Die Kern Workflows Im Rational Unified Process gibt es neun Kern Workflows, in denen die Worker und Activities in logische Gruppen eingeordnet sind. Diese neun Kern-Workflows sind unterteilt in sechs Prozess-Workflows und drei Support-Workflows Core Process Workflows Die sechs Kern-Prozess-Workflows sind: Business Modelling Der Business Modelling Workflow beschreibt, wie mittels so genannter Business- Use-Cases ein Geschäftsprozess abgebildet werden kann. Das so definierte Geschäftsmodell kann als Grundlage für die zu entwickelnden Anforderungen und Funktionalitäten verwendet werden. Requirements Das Ziel des Requirement Workflow ist, zu Beschreiben was das System machen soll. Diese Beschreibung soll Entwickler und Kunden zu einer gemeinsamen Sicht der Anforderungen verhelfen. Es werden außer den funktionalen auch die nichtfunktionalen Anforderungen beschrieben. Zum Workflow gehört auch die Definition einer Benutzungsschnittstelle. Die Resultate dienen unter anderem als Basis zum Planen der Iterationen und zur Berechnung von Kosten und Zeit. Analysis and Design Das Ziel des Analysis and Design Workflow ist es zu zeigen, wie das System in der Implementierungsphase realisiert werden kann. Dazu ist es nötig, die Anforderungen zu verstehen und diese durch Auswahl der geeigneten Implementierungsstrategie in ein System zu transformieren. Implementation Der Zweck der Implementierung ist: ffl Den Code in Schichten und Subsystemen zu organisieren. ffl Komponenten wie Klassen und Objekte zu implementieren. ffl Die entwickelten Komponenten zu testen. ffl Die Komponenten zu ausführbaren Systemen zusammenzufügen. Der Rational Unified Process beschreibt, wie vorhandene Komponenten wiederverwendet werden können, oder wie neu zu entwickelnde Komponenten mit gut definierten Eigenschaften die Wartbarkeit des Systems erhöhen und die Wiederverwendbarkeit erhöhen.

32 18KAPITEL 2. OO-SOFTWAREENTWICKLUNG MIT DEM RATIONAL UNIFIED PROCESS Test Die Ziele des Test Workflows sind: ffl Das Überprüfen der Interaktionen zwischen den Komponenten. ffl Das Überprüfen der korrekten Integration der verschiedenen Komponenten. ffl Sicherstellen, dass die Anforderungen erfüllt werden. ffl Sicherstellen, dass alle bekannten Fehler vor der Auslieferung des Produktes beschrieben werden. Der Rational Unified Process ermöglicht durch Tests in jeder Iteration eine frühe Erkennung von Fehlern und Problemen. Deployment Das Ziel des Deployment Workflows ist es, erfolgreich Produkt-Releases zu erstellen und die Software an den Endnutzer auszuliefern. Er umfasst ein weites Spektrum an Aktivitäten einschließlich: ffl Das Herstellen von externen Releases der Software. ffl Das Verpacken der Software. ffl Das Verteilen der Software. ffl Die Installation der Software. ffl Den Benutzern Hilfe und Unterstützung zu leisten Core Supporting Workflows Die drei Unterstützenden Workflows sind: Configuration and Change Management Dieser Workflow beschreibt, wie die große Anzahl von Resultaten der vielen Worker kontrolliert werden kann. Project Management Dieser Workflow konzentriert sich auf den Aspekt der iterativen Software Entwicklung. Das Ziel ist es dieses durch die Bereitstellung von: ffl Einem Framework zum Managen Software intensiver Projekte. ffl Praktischen Richtlinien zur Planung, Durchführung und Überwachung von Projekten. ffl Einem Framework zum Risiko Management. leichter zu machen. Environment Das Ziel des Environment Workflow ist es, die Software-Entwickler mit den nötigen Werkzeugen und Hilfsmitteln auszustatten.

33 Kapitel 3 Objektorientierte Analyse mit der UML und Use Cases Oliver Klein Software wird immer komplexer, und die Entwickler benötigen Hilfsmittel und Werkzeuge, die den steigenden Anforderungen gerade für den objektorientierten Bereich gerecht werden. In dieser Ausarbeitung wird eine kurze Einführung in die objektorientierte Analyse gegeben und die wesentlichen Elemente der Unified Modeling Language anhand deren Notation und Semantik erklärt. Außerdem wird hier der Ansatz einer Analysemethode vorgestellt, die sich hauptsächlich an Use Cases (Anwendungsfällen) orientiert. Es wird gezeigt, wie ein Softwareentwickler mit Hilfe von Use Cases von einer externen Anwendersicht immer weiter zu einer komplexen inneren Sichtweise eines Systems gelangen kann, indem er den Use Case als Grundlage für den Einsatz weiterer Modellelemente der UML verwendet. 19

34 20 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES 3.1 Einleitung Motivation Mit den Anfängen der objektorientierten Programmiersprachen kam auch das Bedürfnis nach objektorientierten Analyse- und Entwurfsmethoden auf. Anfang der Neunziger Jahre gab es bereits eine Vielzahl von Ansätzen in diesem Bereich, aber meistens waren sie auf einzelne Anwendungsgebiete oder Modellaspekte beschränkt begannen Grady Booch und James Rumbaugh ihre Methoden zusammenzuführen und definierten Ihre Unified Method (UM). Das Konzept der Use Cases, also der Anwendungsfälle, wurde kurze Zeit später von Ivar Jacobson dazugeliefert und nach der Integration und Harmonisierung ihrer Ansätze wurde die UML (Unified Modeling Language) schließlich im November 1997 von der OMG (Object Management Group) standardisiert UML Die UML ist eine Sprache und Notation mit überwiegend grafischen Elementen. Abgesehen davon, dass sie natürlich als Werkzeug für die objektorientierte Softwareentwicklung geschaffen wurde, ist sie ansonsten aber unabhängig von der gewählten Implementierungssprache. Der Schwerpunkt der UML liegt also auf der visuellen Modellierung von Softwaresystemen und bietet somit die Vorteile der Abstraktion durch Modellbildung, Wiederverwendbarkeit, Übersichtlichkeit in komplexen Systemen und Unterstützung der Kommunikation im Entwicklungsprozess. Mit der Vielzahl von Elementen, die die UML bietet, stellt sie ein Instrument dar, das den Entwickler sowohl in der Phase der Spezifikation und der Konstruktion als auch bei der Dokumentation des Softwaresystems unterstützen kann. Die UML ist auf der anderen Seite aber auch nur eine Modellierungssprache, sie stellt keine Methoden für die Analyse und den Entwurf von Softwaresystemen zur Verfügung. In der Softwareentwicklung ist eine einzelne Methode nicht unbedingt universell einsetzbar, sondern meistens von den Rahmenbedingungen des Anwendungsbereiches abhängig. Die UML kann als Basis für verschiedene Methoden verwendet werden Aufbau So wird hier zunächst beschrieben, wie, ausgehend von einer externen Sicht der Anwender, die Anforderungen an ein Softwaresystem mit Hilfe von Akteuren und Use Cases analysiert werden und welche Diagrammtypen der UML diese Analyse und schließlich die Spezifikation des Systemverhaltens unterstützen. Ausgehend von den in dieser Phase gewonnen Diagrammen und der Dokumentation wird anschließend gezeigt, wie die Struktur des Systems aus den Informationen über sein Verhalten abgeleitet werden kann und wie diese Struktur mit den entsprechenden Diagrammen der UML modelliert und dokumentiert wird. Abschließend werden einige Elemente der UML erläutert, die den Aufbau und die Verteilung komplexerer Systeme unterstützen. Es wird allerdings kein vollständiger Überblick über sämtliche Diagramme und Einzelheiten der Modellelemete der UML gegeben, dazu sei auf die Literaturliste im Anhang verwiesen.

35 3.2. USE CASES - DER BEGINN ANALYSE Use Cases - der Beginn Analyse Am Beginn einer Analyse steht eine externe Sichtweise auf die Anforderungen an das System. Die UML unterstützt diese Sicht durch die Spezifikation von Use Case Diagrammen (Anwendungsfalldiagramme). Ein Use Case ist eine Beschreibung einer typischen Interaktion zwischen dem Anwender und dem System und beschränkt sich damit zunächst auf die nach außen, also für den Anwender sichtbaren Anforderungen und Funktionalität. Anstelle von Use Case werden manchmal auch die Begriffe Anwendungsfall, Nutzungsfall oder Geschäftsprozess verwendet. Die vollständigen Anforderungen an das System lassen sich durch die Gesamtheit seiner Use Cases, die Beziehungen der Use Cases untereinander sowie die unterschiedlichen Akteure, die mit dem System interagieren, beschreiben. Der Weg der Use Case gestützten Analyse kann ungefähr durch folgende Schritte beschrieben werden: 1. Beschreibung der Ausgangssituation 2. Problembeschreibung 3. Identifikation der Akteure 4. Identifikation der Prozesse und Anwendungsfälle 5. Beschreibung der Anwendungsfälle Die ersten beiden Schritte fallen nicht speziell in den Bereich der Use Case gestützte Analyse. Sie sind vielmehr Voraussetzung für jede Methode, die man verwenden kann und werden hier nicht weiter behandelt Akteure und die Grenzen des Systems Ein Akteur (engl. actor) ist prinzipiell alles, was mit dem System auf irgendeine Art und Weise von außen in Kontakt steht, sei es durch das Auslösen einer Aktion im System, dadurch dass das System eine Aktion bei ihm auslöst oder beides. Akteure befinden sich also an den Grenzen des Systems. Beispielsweise können Menschen, andere Software oder Hardware oder auch Datenspeicher Akteure in einem System sein. Dabei nehmen sie in Bezug auf das System aber immer ganz bestimmte Rollen ein, wie z.b. Verkäufer, Kunde, Manager, Buchhaltungssystem, Datenbank oder Lagerverwaltung. Eine Person in einer Organisation kann verschiedene Rollen einnehmen, und eine Rolle kann von mehreren Personen eingenommen werden. Akteure sind die Auslöser für Use Cases (man könnte auch sagen ein Akteur führt einen Use Case durch), weshalb es nützlich ist, die Akteure vor den Use Cases zu identifizieren. Ein Akteur kann verschiedene Use Cases auslösen, ein Use Case kann aber auch von verschiedenen Akteuren ausgelöst werden.

36 22 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES Von Akteuren zu Use Cases Hat man die Akteure in einem System erst einmal gefunden, hat man auch einen guten Ausgangspunkt, um die Use Cases, also die Anforderungen an das System zu identifizieren: ffl Welche Funktionalität erwartet jeder Akteur vom System? ffl Wenn das System Daten speichert, welche Akteure greifen au die Daten zu? ffl Muss das System Akteure darüber informieren, wenn es seinen internen Zustand ändert? ffl Gibt es externe Ereignisse, über die das System von einem Akteur informiert werden sollte? Bei dem Beispiel eines Mail-Order Systems zur Geschäftsprozessabwicklung von der Bestellung bis zur Auslieferung der Waren erwartet der Akteur Kunde sicherlich eine Funktion, um den Status seiner Bestellung abfragen zu können, und wenn sich die Preise aufgrund von Preisschwankungen bei den Zulieferern ändern sollten, dann gibt es sicherlich einen Angestellten, der die Preise im Datenbestand des Systems anpassen muss. Um einen Use Case zu beschreiben, hält man sich zunächst an ein typisches Szenario der Abläufe zwischen Akteur und System. In dem vorangegangenen Beispiel könnte ein Szenario für einen Use Case Bestellung aufgeben wie folgt aussehen: 1. Der Use Case beginnt, wenn der Kunde den Befehl " Bestellung aufgeben gewählt hat. 2. Das System zeigt das Bestellformular an. 3. Der Kunde gibt seine persönlichen Daten an. 4. Der Kunde gibt einen Produktcode ein. 5. Für jedes Produkt gibt das System eine Produktinformation und die derzeitige Zwischensumme aus. 6. Der Kunde gibt seine Kreditkarteninformationen ein. 7. Der Kunde wählt den Befehl " Submit. 8. Das System nimmt die Bestellung auf. 9. Das System prüft und belastet die Keditkarte. 10. Das System bestätigt die Bestellung. 11. Das System zeigt dem Kunden die Bestellnummer an und der Use Case endet. Ein Use Case wird aber nicht allein nur durch sein Szenario beschrieben. Eine aussagekräftige Dokumentation sollte ungefähr die folgenden Punkte enthalten:

37 3.2. USE CASES - DER BEGINN ANALYSE 23 Name des Use Case: Ein eindeutiger und aussagekräftiger Name für den Use Case, ggf. mit einer kurzen Beschreibung (ein Satz). Vorbedingung: Zustand des Systems bevor der Use Case beginnen kann. Nicht-funktionale Anforderungen: Antwortzeitanforderungen, Plattformvoraussetzungen, Prioritäten usw. Akteure: Akteure, die den Use Case auslösen können oder anderweitig beteiligt sind. Benutzte Use Cases: Eine Liste der Use Cases, die im Laufe des Szenarios aufgerufen werden. Szenario: Eine Beschreibung des Verlaufs des Use Case. Varianten/Ausnahmen: Alternative Szenarien für Abweichungen und Ausnahmen von diesem Use Case Szenario. Nachbedingung: Zustand des Systems nach erfolgreicher Beendigung des Use Case Use Case Diagramme Ein Use Case Diagramm beschreibt die Zusammenhänge zwischen der Menge von Use Cases und den Akteuren, die an ihnen beteiligt sind. Dabei stehen die Akteure mit den von ihnen ausgelösten Use Cases in Verbindung. Akteure werden in der Regel als Strichmännchen dargestellt und ein Use Case als Ellipse, die den Namen des Use Case enthält. Abbildung 3.1: Use Case Diagramm Beispiel Es kommt häufig vor, dass Teile eines Szenarios in mehreren Use Cases auftauchen, z.b. wenn sich ein Akteur zu Beginn verschiedener möglicher Aktionen über ein Login erst bei dem System anmelden muss. Dann sollte man diesen Teil eines Szenarios durch einen eigenen Use Case beschreiben. Das gleiche gilt, wenn ein Szenario möglicherweise

38 24 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES zu komplex wird. In dem oben beschrieben Use Case Bestellung aufgeben ist beispielsweise nicht genauer beschrieben, wie das System die Produktinformationen erhält, die es dem Kunden nach Eingabe eines Produktcodes anzeigt. In Abbildung 3.1 ist der Use Case Produkt-info geben ausgelagert und durch die Verbindung zum Datenbankakteur wird deutlich, woher die Information über ein Produkt stammt. Die uses-beziehung (dt. benutzt ) macht deutlich, dass das Verhalten von Produkt-Info geben im Use Case Bestellung aufgeben mit genutzt wird. Die Pfeilspitze zeigt dabei immer auf den Use Case, " der sein Verhalten zur Verfügung stellt. Ein weiterer Verbindungstyp zwischen zwei Use Cases ist die extends-beziehung (dt. erweitert ). Sie wird verwendet, wenn ein Use Case praktisch nur einen Sonderfall eines " anderen darstellt. In Abschnitt ist z.b. nur ein sogenanntes Happy-Day-Szenario " beschrieben, in dem Ausnahmen und Sonderfälle völlig unberücksichtigt bleiben. Z.B. könnte die Prüfung der Kreditkarteninformationen ergeben, dass der Kunde nicht kreditwürdig ist, oder aber es gibt Großkunden, die spezielle Rabatte erhalten, was Auswirkungen auf die Preisberechnung hat (vgl. Abbildung 3.1). Damit ein Szenario nicht zu komplex wird, kann man Abweichungen vom normalen Ablauf in eigenen Use Cases behandeln, in denen nur noch festgehalten wird, an welchen Stellen sie sich vom ursprünglichen Use Case unterscheiden. Ein umfassendes Beispiel zur Anwendung von Use Cases zur Analyse findet man bei [SW98]. 3.3 Vom Use Case zu seinen Verhaltensdiagrammen Die einzelnen Verhaltensdiagramme in der UML dienen zur Darstellung der dynamischen Sachverhalte eines Use Cases. Ausgangspunkt der Modellierung ist hier immer die Betrachtung eines Szenarios, das in der Dokumentation eines Use Cases beschrieben wurde Aktivitätsdiagramme In der UML ist ein Aktivitätsdiagramm eine besondere Form eines Zustandsdiagramms, wobei jeder Zustand eine Aktivität darstellt. Eine Aktivität ist in diesem Sinne eine interne Aktion mit einer oder mehreren ausgehenden Transitionen. Eine Transition wird automatisch nach Beendigung der internen Aktion ausgeführt. Bei mehreren möglichen Transitionen werden diesen eindeutig unterscheidbare Bedingungen zugeordnet. Manchmal werden Aktivitätsdiagramme auch Ablaufdiagramme genannt und sie ähneln sehr den prozeduralen Flussdiagrammen. Grundsätzlich kann man Aktivitätsdiagramme für Klassen, Operationen und Use Cases (Anwendungsfälle) erstellen. An dieser Stelle wird aber nur auf den an Use Cases orientierten Einsatz von Aktivitätsdiagrammen eingegangen, also mehr eine konzeptionelle Sichtweise eingenommen. Bei Diagrammen aus Spezifikations- oder Implementierungsperspektive ist eine Aktivität eine Methode einer Klasse. Ein Aktivitätsdiagramm bildet das Szenario eines Use Cases ab. Dabei wird ein Schritt aus dem Szenario durch ein abgerundetes Rechteck dargestellt und mit einer Beschreibung

39 3.3. VOM USE CASE ZU SEINEN VERHALTENSDIAGRAMMEN 25 der Aktion versehen. Die Transitionen werden durch Pfeile dargestellt und, wenn erforderlich, mit einer in eckige Klammern gefassten Bedingung versehen. Ein Aktivitätsdiagramm enthält immer einen Startpunkt und i.d.r. mindestens einen Endpunkt. In Abbildung 3.2 ist das Szenario des Use Cases Bestellung aufgeben aus Abschnitt dargestellt, wobei die Möglichkeit, einzelne Aktionen abzubrechen, hinzugefügt wurde. Der Übersichtlichkeit wegen wurden die ersten fünf Aktionen als Cancelable Actions zusammengefasst, denn auf diese Weise braucht die Transition mit der Bedingung [cancel] nur einmal in das Diagramm aufgenommen zu werden. Abbildung 3.2: Aktivitätsdiagramm Beispiel Um Entscheidungspunkte zu verdeutlichen, kann als weiteres Element in Aktivitätsdiagrammen auch eine Raute als Verzweigungspunkt verwendet werden. Aus ihr können beliebig viele Transitionen herausführen, die mit eindeutigen Bedingungen versehen sein müssen. Abbildung 3.3: Entscheidungspunkte und Parallelität Um parallele Abläufe zu modellieren, wird eine kleine dicke Linie verwendet, an der

40 26 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES sich eine Transaktion aufteilt oder mehrere Transaktionen synchronisiert werden. (Vgl. Abbildung 3.3) Die folgenden beiden Diagrammtypen, das Sequenzdiagramm und das Kollaborationsdiagramm, beschreiben das Systemverhalten mit Blickwinkel auf die an einem Use Case beteiligten Objekte und die Interaktion zwischen diesen Objekten. Die Interaktion findet dabei durch den Austausch von Nachrichten statt. Man nennt diese Diagramme auch Interaktionsdiagramme Sequenzdiagramme Auch beim Sequenzdiagramm steht ein einzelner Use Case im Vordergrund. Zunächst kommt es darauf an, innerhalb eines Use Cases die Objekte zu identifizieren, die maßgeblich miteinander kommunizieren. Dazu gehören auch alle an dem Use Case beteiligten Akteure. Anhand des Szenarios lassen sich evtl. auch schon die Nachrichten identifizieren, über die die Objekte miteinander kommunizieren. In einem Sequenzdiagramm werden nun die Objekte horizontal nebeneinander und die Nachrichten nach ihrem zeitlichen Auftreten untereinander angeordnet. Solange ein Objekt existiert, wird es durch eine senkrechte gestrichelte Linie dargestellt. Nachrichten sind waagerechte Pfeile mit geschlossener Spitze zwischen den Objekt-Linien, über denen die Nachricht in der Form nachricht(argumente) notiert wird. Eine Antwort auf die Nachricht wird entweder durch einen eigenen Pfeil mit offener Spitze, oder durch eine Notation antwort:= nachricht() auf dem Nachrichten-Pfeil dargestellt. Ein Objekt erhält einen Steuerungsfocus, wenn es eine Nachricht empfängt, die es abarbeiten muss. Dargestellt wird der Steuerungsfokus durch einen dicken weißen Balken auf der Objekt-Linie, der anzeigt, ob ein Objekt aktiv ist. Solange ein Objekt auf eine Antwort wartet, ist es ebenfalls aktiviert. Abbildung 3.4: Darstellung eines Objekts im Sequenzdiagramm Die Konstruktion eines Objekts wird, wie ebenfalls in Abbildung 3.4 verdeutlicht, durch eine Nachricht (new()), die auf das Objektsymbol trifft, angezeigt. Bei der Destruktion eines Objekts, die durch eine entsprechende Nachricht eingeleitet wird (delete()), beendet ein kleines Kreuz die Lebenslinie und den Steuerungsfocus des Objekts.

41 3.3. VOM USE CASE ZU SEINEN VERHALTENSDIAGRAMMEN 27 Abbildung 3.5 zeigt ein Sequenzdiagramm eines relativ einfachen Use Case Bestellung suchen im Zusammenhang mit einem Rücktritt von dieser Bestellung. Der Kunde sendet zunächst an das Objekt Bestellrücktritt Dialog die Nachricht findebestellung(), worauf dieses ein Dialog-Objekt zum Suchen einer Bestellung erzeugt (display()). Nach dem Setzen der Bestellnummer und der Aufforderung zum Suchen wird die Bestellung aus dem Datenbank-Objekt geholt. Zum Schluss sendet der Suchdialog an sich selbst die Nachricht zeige(bestellung) und der Steuerungsfocus geht zurück an den Kunden. Die Technik, eine Nachricht an sich selbst zu versenden, wird auch Selbstdelegation genannt. Um besser zu verdeutlichen, von welcher Aktion möglicherweise weitere Nachrichten ausgehen, kann seitlich versetzt einen weiteren Steuerungsfocus für die Selbstdelegation an die Objektlinie gezeichnet werden. In dem Beispiel wurde darauf verzichtet, da die Aktion zum Anzeigen der Bestellung keine weiteren Nachrichten mehr auslöst. Abbildung 3.5: Sequenzdiagramm für den Use Case Bestellung suchen Die Nachrichten in Interaktionsdiagrammen können in der UML durch die Verwendung von Bedingungen und Iterationsmarken erweitert werden. Bedingungen werden in eckige Klammern vor die Nachricht geschrieben. Sie werden überwiegend eingesetzt, um unterschiedliche Wege durch ein Szenario darstellen zu können, was das Sequenzdiagramm allerdings eher unübersichtlichmacht. Ein Ausweg ist es, verschiedene Szenarien (oder einfach nur mehrere Sequenzdiagramme) für einen Use Case zu schreiben, welche jeweils nur eine bzw. nur eine Teilmenge aller Bedingungen abdecken. Ein Sternchen " * wird verwendet, um Iterationen anzuzeigen, also das mehrfache Senden einer Nachricht. Iteration und Bedingung können auch kombiniert werden, beispielsweise um auszudrücken, woraus sich die Iteration ergibt (*[für alle Auftragspositionen]holePreis()). Sequenzdiagramme eignen sich außerdem zur Darstellung nebenläufiger Prozesse. Nebenläufigkeit beginnt mit dem Senden einer asynchronen Nachricht, die im Sequenzdiagramm durch eine halbe Pfeilspitze dargestellt wird.

42 28 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES Kollaborationsdiagramme Während Sequenzdiagramme besonders gut den zeitlichen Ablauf für ein Szenario darstellen, dienen Kollaborationsdiagramme in erster Linie zur Modellierung der topographischen Beziehungen zwischen den Objekten bzw. Klassen. Kollaborationsdiagramme beschreiben im Prinzip die gleichen Abläufe wie Sequenzdiagramme, nämlich Interaktionen mittels Austausch von Nachrichten, die Klassenbeziehungen in einem Diagramm sind aber wesentlich besser zu erkennen. Zwischen Objekten, die irgendwann einmal Nachrichten austauschen, besteht nur eine Assoziationslinie. Alle Nachrichten, die im Laufe eines Szenarios ausgetauscht werden, werden an diese Linie geschrieben und mit einem Richtungspfeil versehen. Der zeitliche Ablauf der Kommunikation wird durch Nummerierung der Nachrichten verdeutlicht. Dabei gibt es unterschiedliche Nummerierungsschemata. Die einfachste Möglichkeit ist eine aufsteigende Nummerierung der Nachrichten. Verwendet man eine dezimale Nummerierung wird zusätzlich deutlich, welche Operation bzw. Nachricht von welcher anderen ausgelöst wird. Abbildung 3.6: Kollaborationsdiagramm Abbildung 3.6 zeigt einen Teil eines Szenarios zur Artikelreservierung. Man kann sich vorstellen, dass dieses Szenario von einem Use Case Bestellung aufgeben benutzt wird, um die Artikel im Lager bereits vor der Auslieferung als bestellt zu kennzeichnen. In der Darstellung wird zwischen Klassen und konkreten Objekten unterschieden. Beispielsweise bezieht sich die Nachricht 1.1 auf ein Objekt b der Klasse Bestellung und liefert mit jeder Iteration ein Objekt bpos der Klasse Bestellposition. Die Nachrichten 1.1.1, und werden bei jeder Iteration von Nachricht 1.1 wiederholt. Sequenzdiagramme und Kollaborationsdiagramme bilden den Anfang einer umfangreicheren Klassendefinition, die Attribute und Operationen mit einschließt. Zuvor kann man noch einen Blick auf Zustände einzelner zentraler Objekte im System werfen, um auf diese Weise ihr dynamisches Verhalten besser zu verstehen.

43 3.3. VOM USE CASE ZU SEINEN VERHALTENSDIAGRAMMEN Zustandsdiagramme Ein Zustandsdiagramm zeigt eine Folge von Zuständen, die ein Objekt einer bestimmten Klasse im Laufe seines Lebens annehmen kann. Aus Klassensicht beschreibt ein Zustand eine Menge möglicher Attributwerte, wobei nicht jede Änderung eines Attributwertes gleichzeitig den Übergang in einen neuen Zustand bedeutet. Es ist wichtig, nur solche Änderungen in den Attributwerten zu betrachten, die das Verhalten eines Objekts entscheidend beeinflussen. Ein Zustandsdiagramm wird durch einen endlichen Automaten mit einer endlichen, nicht-leeren Menge von Zuständen, einer Menge von Ereignissen, Zustandsübergangsfunktionen, einem Anfangszustand und mindestens einem Endzustand beschrieben. Eine Zustandsübergangsfunktion (Transition) besteht aus drei jeweils optionalen Teilen: Ereignis[Bedingung]/Aktion. Ein Ereignis ist normalerweise keiner besonderen Klasse zugeordnet, ändert aber die Bedingungen, die für ein Objekt in einem bestimmten Zustand entscheidend sind. Ein Zustand besteht aus einem Namen, den Zustandsvariablen und einer Menge möglicher Aktivitäten, die ausgeführt werden, wenn der Zustand eintritt, verlassen wird oder solange er aktiv ist. Für einen einzelnen Use Case bewirken Zustandsdiagramme nicht sehr viel. Objekte, die ein komplexes Verhalten zeigen, sind i.d.r. an unterschiedlichen Use Cases beteiligt. Zustandsdiagramme eignen sich daher besser, um das Verhalten eines Objekts über mehrere Use Cases hinweg zu beschreiben. In Abbildung 3.7 wurden die Zustandsvariablen weggelassen. Das Diagramm zeigt die Zustände einer Bestellung in einem möglichen Use Case Bestellung ausliefern. Dabei sind andere Use Cases beteiligt, um die entsprechenden Ereignisse zu ermöglichen (dazu könnte z.b. eine Lagerverwaltung zählen, die bekannt gibt, wann eine Position wieder vorrätig ist). Ein Nachteil an Zustandsdiagrammen ist in dieser Hinsicht sicherlich der fehlende Bezug zu konkreten Use Cases aus der vorangegangenen Analyse. Abbildung 3.7: Zustandsdiagramm einer Bestellung

44 30 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES In dem Beispiel aus Abbildung 3.7 beginnt der Zustand in Prüfung, nachdem die erste Auftragsposition geholt wurde. Das Schlüsselwort do leitet Aktivitäten ein, die für die Dauer des Zustands ausgeführt werden (entry und exit kennzeichnen Aktivitäten beim Eintritt bzw. beim Verlassen eines Zustands). Vereinfachungen in Zustandsdiagrammen werden durch die Verwendung von Oberzuständen ermöglicht. Dies ist z.b. sinnvoll, wenn mehrere Zustände über Transitionen (mit gleichen Ereignissen, Bedingungen oder Aktionen) in ein und denselben Zustand übergehen. In diesem Fall werden sie in einem Oberzustand zusammengeführt, von dem dann nur noch eine Transition ausgeht. In Abbildung 3.7 könnten z.b. die drei Hauptzustände über ein Ereignis abgebrochen in einen Endzustand übergehen, um zu modellieren, dass eine Bestellung zu jedem Zeitpunkt vor ihrer Auslieferung abgebrochen werden kann. Diese drei Zustände bilden somit den Oberzustand Aktiv, der auf eine Transition abgebrochen reagiert. Parallele Zustände lassen sich ebenfalls modellieren, man erhält dann ein nebenläufiges Zustandsdiagramm. Die parallelen Zustandräume beziehen sich dabei auf unterschiedliche Kontexte (Um beispielsweise eine Bestellung für die Auslieferung zu autorisieren, wird neben der Prüfung der Warenverfügbarkeit auch eine Zahlungsautorisierung durchgeführt.) 3.4 Vom Verhalten zur logischen Struktur Die bisherige Analyse und die vorgestellten Diagrammtypen sind sehr gut geeignet, um einerseits die Anforderungen eines Systems in Form von Use Cases heraus zu arbeiten, und andererseits mit Hilfe der Aktivitäts-, Sequenz-, Kollaborations- und Zustandsdiagramme das Verhalten der beteiligten Objekte zu modellieren. Dabei orientieren sich die Verhaltensdiagramme an den Use Cases, wodurch sichergestellt werden kann, dass die formulierten Anforderungen auch erfüllt werden können. Ist dieser Teil der Analyse abgeschlossen, hat der Softwareentwickler bereits ein gutes Verständnis davon, was das System leisten wird und wie sich einzelne Teile des Systems verhalten sollen. Dabei gelangt er von einer äußeren Sichtweise immer mehr zu einer inneren Sicht von Objekten und Klassen, und zu einem ersten Entwurf davon, was diese Klassen im einzelnen Leisten sollen. In einem größeren System treten dabei aber meistens viele sehr komplexe und auch abstrakte Objekte bzw. Klassen auf, so dass es sich lohnt, diese auch geeignet zu strukturieren. Klassen und Klassendiagramme nehmen innerhalb der UML den größten Bereich an Modellierungskonzepten ein, denn sie befinden sich sozusagen an der Nahtstelle zwischen Modellierung und Implementierung Klassen Eine Klasse definiert die Attribute, Operationen (Methoden) und die Semantik einer Menge von Objekten. Die ersten Gedanken über Klassen und ihre Objekte macht sich der Entwickler bereits beim Erstellen der Sequenz- und Kollaborationsdiagramme. Die Namen einiger zentraler Klassen, die Nachrichten, die sie empfangen können und ggf. einige

45 3.4. VOM VERHALTEN ZUR LOGISCHEN STRUKTUR 31 Attribute, die sie kennen müssen, sind schon aufgezeigt worden. Die Nachrichten, die ein Objekt empfangen kann, sind möglicherweise die Methoden seiner Klasse, und die Attribute und Antworten auf Nachrichten möglicherweise Attribute der Klasse. In der UML werden Klassen durch dreigeteilte Rechtecke dargestellt. Eine Klasse besteht mindestens aus ihrem Namen, der immer mit einem Großbuchstaben beginnen sollte. Der Name steht im oberen Teil. Im mittleren Teil werden die Attribute aufgelistet und im unteren Teil die Operationen. Abbildung 3.8: Klassennotation und Beispiele Ist eine Klasse in eine Paketstruktur eingebunden, erscheint der Paketname vor dem Klassennamen. Als Erweiterung bietet die UML die Möglichkeit der Klassifikation einer Klasse durch Stereotypen (dies ist ein fortgeschritteneres Konzept und wird eingehender von M. Fowler und K. Scott [FS98] sowie bei B. Oestereich [Oes97] behandelt). Beispiele für Stereotypen sind Schnittstellen <<interface>>, Kontrollobjekte <<control objekt>> oder Hilfsmittel <<utility>>. Um z.b. abstrakte Klassen zu kennzeichnen, wird als Merkmal die Bezeichnung abstract} verwendet. In dem Beispiel aus Abbildung 3.8 hat das Attribut radius die Zusicherung radius>0}. Zusicherungen schränken in der Regel zusätzlich zur Typangabe eines Attributs seinen Wertebereich ein. Initialwerte legen den Wert fest, den das Attribut gleich nach dem Erzeugen des Objekts annimmt. Über die Operationen bzw. Methoden kommunizieren Objekte untereinander. Die Signatur einer Methode enthält üblicherweise mindestens den Namen und wenn es erforderlich ist eine Parameterliste, welche die Argumente einer Nachricht festlegt. Die vollständige UML-Syntax für Operationen lautet: Sichtbarkeit Name (Parameterliste):Rückgabetypausdruck Eigenschaften}.

46 32 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES Beziehungselemente und Klassendiagramme Damit Objekte untereinander Nachrichten austauschen können, müssen ihre Klassen über Beziehungen miteinander verbunden sein. Diese Beziehungen werden in der UML durch Klassendiagramme modelliert. Während die vorangegangenen Diagramme zur Darstellung dynamischer Sachverhalte des Systems dienten, sind Klassendiagramme für die statischen Elemente und somit für die Struktur des Modells zuständig. Die wichtigsten Beziehungselemente sind: ffl Assoziation ffl Vererbung ffl Aggregation ffl Komposition Eine Assoziation beschreibt eine Verbindung zwischen Klassen. Dabei müssen die beteiligten Klassen nichtnotwendigerweise verschieden sein. Wenn eine Klasse eine rekursive Beziehung besitzt, wird davon ausgegangen, dass die Beziehung dann zwischen zwei unterschiedlichen Objekten, also Instanzen dieser Klasse besteht. Die Multiplizität einer Klasse gibt an, mit wie vielen Objekten einer anderen Klasse ein Objekt assoziiert sein kann. Kann diese Anzahl schwanken, gibt man die Grenzen dieses Intervalls an. Liegt das Minimum bei 0, ist die Beziehung optional. Gibt es keine obere Grenze, benutzt man das *-Symbol. Jede Beziehung sollte außerdem mit einem beschreibenden Namen versehen werden. Sie besitzt zwei Rollen. Eine Rolle ist die Sichtweise eines Objekts durch das jeweils gegenüberliegende Objekt in einer Beziehung. Abbildung 3.9: Assoziationsbeziehung Abbildung 3.9 zeigt auch eine gerichtete Assoziation. Der Pfeil zeigt dabei in die Richtung der Navigierbarkeit. In dem Beispiel bedeutet dies, dass eine Rechnung zwar auf ihre Anschrift zugreifen kann, eine Anschrift aber nicht ihre Rechnungen kennt.

47 3.4. VOM VERHALTEN ZUR LOGISCHEN STRUKTUR 33 Das nächste Beziehungselement ist die Vererbungsbeziehung. Über die Vererbung können Klassenhierarchien aufgebaut werden. Die Vererbung ist ein nützliches Prinzip zur Abstrahierung bzw. Generalisierung einer Menge von ähnlichen Klassen. Besitzen mehrere Klassen gleiche Attribute und Methoden, können diese in einer allgemeinen Oberklasse beschrieben werden, die sie dann ihren Unterklassen zur Verfügung stellt bzw. vererbt. Die Unterklassen können daneben auch noch zusätzliche Attribute und Methoden besitzen. Die Beziehung zwischen Ober- und Unterklassen wird durch einen Diskriminator charakterisiert, wobei es auch möglich ist, Unterklassen bezüglich verschiedener Diskriminatoren in ein Modell aufzunehmen. Ein anderer Diskriminator für die Vererbungsbeziehung in Abbildung 3.10 kann z.b. auch dasfortbewegungsmedium (Schiene, Straße, Wasser) sein. Abbildung 3.10: Assoziationsbeziehung Die Aggregation und die Komposition dienen zur Modellierung einer " Ganzes-Teile- Hierarchie. Unter einer Aggregation versteht man die Zusammenfassung eines Objekts aus einer Menge von Einzelteilen. Man bezeichnet die Klasse dieses zusammengesetzten Objekts dann als Aggregatklasse und ihre Teile als Teilklassen. Sinn einer Aggregation ist die zentrale und übergeordnete Rolle der Aggregatklasse. Sie nimmt stellvertretend für ihre Teile alle Aufgaben wahr, indem sie empfangene Nachrichten an die Teile weiterleitet. Das bedeutet, dass solche Nachrichten gar keine Veränderungen in der Aggregatklasse selbst bewirken. Trotzdem müssen alle Operationen, die sich auf die Teile beziehen, über die Aggregatklasse abgewickelt werden. Man nennt diesen Vorgang auch Propagieren von Operationen. Im Gegensatz zur Komposition kann ein Teil auch mehreren Aggregaten zugeordnet sein. Die Komposition ist eine strengere Form der Aggregation, denn hier sind die Teile existenzabhängig. Dies bedeutet, dass alle Teile zusammen mit dem Ganzen, also dem Aggregat, entstehen und auch gelöscht werden, was zwangsläufig die Konsequenzen hat, dass die Kardinalität auf der Seite der Aggregatklasse nur 1 sein kann. Für Teile mit einer variablen Multiplizität (1..*) gilt, dass sie nicht gemeinsam mit dem Ganzen erzeugt werden, sondern erst, wenn sie gebraucht werden.

48 34 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES Abbildung 3.11: Aggragationsbeziehung Abbildung 3.12: Kompositionsbeziehung Subsysteme und Paketdiagramme Spätestens bei den Klassendiagrammen wird der Entwickler erkennen, welchen Umfang und Komplexität ein System bereits angenommen hat. Der große Vorteil der UML, die Übersichtichkeit und einfache Lesbarkeit der Diagramme, geht verloren, wenn durch die Komplexität des Systems eine kompakte Darstellung unmöglich macht. Dieser Abschnitt beschäftigt sich deswegen mit der Zerlegung eines Systems in kleinere Subsysteme bzw. Pakete. Bei der Zerteilung in Subsysteme können verschiedene Ansätze verfolgt werden. Eine rein funktionale Zerlegung orientiert sich zwar in gewisser Weise an den Use Cases, basiert aber noch auf einer Trennung von Prozeß und Daten [FS98]. Andere Architektur-Muster sind das " Three-Tier -Modell, ein Drei-Schichten-Modell aus User Interface, Business Rules und Database oder das " Pipe and Filter -Modell, bei dem sich jedes Subsystem an einem Datenpool bedient, die Daten verarbeiten und den Output zurück in den Pool gibt. Ein drittes, wirklich objektorientiertes Modell nach [SW98] stellt die Daten und die mit ihnen verbundenen Funktionen in den Mittelpunkt der Subsysteme, was flexiblere

49 3.4. VOM VERHALTEN ZUR LOGISCHEN STRUKTUR 35 Interaktionen ermöglicht. Hier sitzt die einzelne Funktion vollständig in einem einzigen Subsystem. Als Eigenschaften eines Subsystems ergeben sich daraus eine abgegrenzte und homogene Funktionalität, ein starker interner Zusammenhalt, eine lose Bindung und eine minimale Kommunikation mit anderen Subsystemen. Nach einer ersten Einteilung in Subsysteme können diese Eigenschaften überprüft werden, indem die " globalen Use Cases Schritt für Schritt betrachtet werden, um festzustellen, welches Subsystem einen Schritt ausführt. Auf diese Weise gelangt der Entwickler evtl. zu einer weiteren Zerteilung der Use Cases und zu einer Zuordnung zu den Subsystemen. Außerdem werden die Abhängigkeiten zwischen den Subsystemen deutlich. Aus Sicht eines Subsystems werden in seinem Use Case Diagramm andere abhängige Subsysteme als Akteure dargestellt. Subsysteme bilden für den Entwicklungsprozeß organisatorische Einheiten, die einzeln getestet und schrittweise (iterativ) implementiert und integriert werden können. Pakete und Subsysteme unterscheiden sich im Grunde nicht voneinander. In der Regel wird aber von Paketen gesprochen, wenn der Entwickler bereits eine Implementationssicht angenommen hat und in großen Systemen die Klassen nach logischen oder physischen Zusammenhängen gliedern möchte. Vorhandene Bausteine, wie Bibliotheken, Schnittstellen usw. werden z.b. als Pakete in das Modell mit aufgenommen und in Paketdiagrammen dargestellt. In der UML wird ein Aktenregister als Symbol für ein Paket benutzt und Abhängigkeiten zwischen den Paketen werden durch gestrichelte Pfeile dargestellt Implementierungsdiagramme Komponentendiagramme und Einsatzdiagramme dienen in der UML zur Darstellung von Implementierungssachverhalten. Mit ihnen sollen hauptsächlich die physikalischen Charakteristika eines Systems hervorgehoben werden, sofern sich ihre Betrachtung überhaupt lohnt. Komponentendiagramme zeigen die Struktur und Aufteilung des Systems in physische Teile von Programmcode, wie z.b. Quellcode, Binärcode oder ausführbare Programme (Abbildung 3.13). Abbildung 3.13: Notation einer Komponente Einsatzdiagramme (bzw. Verteilungsdiagramme) zeigen die Verteilung der Komponenten des Systems auf Knoten. Ein Knoten ist ein zur Laufzeit physisch vorhandenes Objekt wie ein Computer oder Prozessor. Außerdem kann man Informationen über die Konfiguration der Knoten mit einem Einsatzdiagramm dokumentieren.

50 36 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES Abbildung 3.14: Notation eines Einsatzdiagramms 3.5 Iterative Projektplanung mit Use Cases Der letzte Abschnitt beschäftigt sich damit, wie Use Cases eingesetzt werden können, um einen iterativen Softwareentwicklungsprozeß zu unterstützen. Dabei wird an dieser Stelle nur auf die Konstruktionsphase eingegangen (für eine Beschreibung des gesamten Prozesses siehe [SW98] und [FS98]) Der Einsatz von Use Cases in der Konstruktionsphase In der Konstruktionsphase wird ein System in einer Folge von Iterationen ausgearbeitet und implementiert, wobei jede Iteration selbst als ein kleiner Wasserfallprozess angesehen werden kann, der aus den folgenden Schritten besteht: ffl Vorbereitung ffl Anforderungsdefinition ffl Analyse & Design ffl Implementierung ffl Test ffl Release In jeder Iteration wird also ein Teil der Funktionalität des Systems vollständig entwickelt und implementiert. Welche Funktionen zu welchem Zeitpunkt erstellt werden ist dabei von einer Bewertung der Use Cases abhängig. Die Absicht dabei ist, die Risiken unter Kontrolle zu haben und die problematischen Aspekte nicht erst am Ende des Projekts zu bearbeiten. Die Verteilung der Use Cases bzw. Szenarien findet unter folgenden Gesichtspunkten statt: 1. risikobehaftete Use Cases 2. Basisfunktionalität 3. zentrale Funktionen 4. Schnittstellen

51 3.6. ABSCHLIEßENDE ANMERKUNGEN Ausnahmeszenarien 6. erweiterte Szenarien Bei jeder Iteration fließen die ausgewählten Szenarien sowie das Ergebnis der vorangegangenen Iteration in die Vorbereitungsphase ein. Am Ende erhält der Entwickler eines Systems jedes mal einen ausführbaren Prototypen, dessen Funktionsumfang mit jeder Iteration immer weiter zunimmt. 3.6 Abschließende Anmerkungen Der Einsatz der unterschiedlichen Elemente der UML hat gezeigt, dass sich viele Aspekte eines zu entwickelnden Systems bereits in der Analysephase detailliert ausarbeiten lassen. Bei der Anforderungsdefinition hat sich gezeigt, dass die Anwendungsfälle, also Use Cases, ein gutes Konzept darstellen, da sie eine äußere Sicht auf das System ermöglichen, die eng mit der Sicht der späteren Nutzer verbunden ist. Ein komplettes Beispiel für die Verwendungsmöglichkeiten von Use Cases gibt das Buch von G. Schneider und J. P. Winters [SW98]. Die Meinungen über den Grad des Einsatzes von Use Cases gehen allerdings auseinander. Ivar Jacobson geht beispielsweise davon aus, dass etwa 20 Use Cases für ein 20- Personenjahr ausreichend seien, während M. Fowler und K. Scott [FS98] davon berichten, dass sie selbst in einem Projekt von ähnlichem Umfang mehr als das Fünffache davon benutzten. Die gleichen Probleme tauchen bei der Frage auf, wie umfangreich der Einsatz der übrigen Diagramme ausfallen sollte. Einerseits erhöht der Einsatz von (UML- )Diagrammen die Vollständigkeit der Dokumentation, verbessert die Kommunikationsgrundlagen und vertieft das Verständnis des Systems. Auf der anderen Seite bindet die Erstellung der Diagramme Ressourcen. In dieser Ausarbeitung sind auch beiweitem nicht alle Konzepte der UML zur Sprache gekommen. Einen umfassenderen Überblick bietet hier B. Oestereich [Oes97]. Auch die UML selbst ist keineswegs bereits am Ende ihrer Entwicklung angelangt, auch wenn sie jetzt schon so viele Konzepte anbietet, dass wohl eher selten alle in einem Projekt genutzt werden. Informationen über den aktuellen Stand der Unified Modeling Language findet man bei den Entwicklern der UML [Rat].

52 38 KAPITEL 3. OO-ANALYSE MIT DER UML UND USE CASES

53 Kapitel 4 Objektorientierter Entwurf mit Frameworks und Entwurfsmustern Maik Höft In diesem Artikel wird das Konzept der Entwurfsmuster und der Frameworks vorgestellt und mittels ausgewählter Beispiele verdeutlicht. Es werden Möglichkeiten aufgezeigt, Entwurfsmuster zu beschreiben, zu klassifizieren und sinnvoll anzuwenden. Auch Frameworks werden hinsichtlich verschiedener Kriterien geordnet. Darüber hinaus werden Vor- und Nachteile der Frameworkverwendung, sowie Probleme bei der Frameworkentwicklung aufgeführt. 39

54 40 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN 4.1 Einleitung Entwurfsmuster und Frameworks Entwurfsmuster und Frameworks sind Konzepte, die es Software-Entwicklern erleichtern, wiederverwendbare Software zu schreiben, um somit möglichst wenig Zeit damit zu verlieren, bereits entwickelten Code neu zu schreiben. Diese Konzepte sind in ihren ersten Anwendungen meist nicht ohne Probleme einzusetzen, so dass viele Entwickler aus Furcht vor Zeitmangel lieber auf die alten Methoden zurückgreifen, die ihnen vertraut sind. Doch die zusätzlich investierte Zeit am Anfang macht sich später bei der erneuten Verwendung von bereits durchdachten Konzepten bezahlt, so dass im Endeffekt viel effektiver mit solchen Konzepten gearbeitet werden kann. In diesem Artikel sollen beide Konzepte beschrieben werden und mittels verschiedener Beispiele verdeutlicht werden Aufbau des Artikels Der erste Abschnitt des Artikels behandelt die Thematik der Entwurfsmuster und beginnt mit einer anschaulichen Definition von Entwurfsmustern. Diese Definition wird mittels eines Beispiels, dem "Kompositum", veranschaulicht. Danach wird ein einheitliches Format zur Beschreibung von Entwurfsmustern vorgestellt und Möglichkeiten aufgezeigt, Entwurfsmuster zu klassifizieren. Am Ende des ersten Abschnittes werden Vorschläge für eine effiziente Suche von passenden Entwurfsmustern gegeben und abschließend noch eine korrekte Anwendung des gefundenen Entwurfsmusters besprochen. Der zweite Abschnitt behandelt die Thematik der Frameworks. Nach der Definition folgt eine Klassifizierung der verschiedenen Frameworks. Danach werden Vorteile bei der Verwendung von Frameworks aufgezeigt, sowie Probleme bei deren Entwicklung genannt. Abschließend erfolgt eine Beschreibung des Prozesses der Frameworkentwicklung. Diese beiden Abschnitte werden durch eine kurze Zusammenfassung abgeschlossen. 4.2 Einleitung - Entwurfsmuster Motivation Bei der Entwicklung wiederverwendbarer objektorientierter Software enstehen im Allgemeinen viele Probleme und im Besonderen noch mehr Probleme für unerfahrene Programmierer, die sich im Laufe der Zeit noch keine oder wenige eigene objektorientierten Lösungsstrategien angeeignet haben. Wie in allen Bereichen des Leben ist es sicherlich von Vorteil, bereits von anderen gelöste Probleme selber nochmal zu lösen, um ein gewisses Gespür für die Materie und die Philosophie, die dahinter steckt, zu erhalten. Doch bei der Vielzahl der Herausforderungen ist es unmöglich, alles selber zu ergründen, und deshalb sollte es möglich sein, auf den Erfahrungsschatz anderer Leute zuzugreifen, um effizient die gestellten Aufgaben bewerkstelligen zu können. Das Problem ist jedoch, dass die bewährten Lösungsansätze, die von erfahrenen Programmierern intuitiv (oder auch bewusst) angewendet werden, selten so festgehalten werden, dass ein Anfänger auf diesen

55 4.3. BEISPIEL: ENTWURF DER DOKUMENTSTRUKTUR EINES EDITORS 41 Schatz zugreifen kann. Es ist also notwendig, eine Art Spezifikationssprache zu entwickeln, die gemachte Programmiererfahrung festhält. Dieses wird durch so genannte Entwurfsmuster bewerkstelligt, die jedes einzelne für sich eine Lösung für eine ganze Klasse von Problemen anbieten. In dieser Ausarbeitung wird beispielhaft auf eine Problemstellung und eine dazugehörige Lösung, die durch ein Entwurfsmuster beschrieben wird, eingegangen. Darüber hinaus werden Beschreibungsmöglichkeiten und Klassifizierungsmöglichkeiten von Entwurfsmustern vorgestellt. An dieser Stelle sei auf das Buch [G + 97] verwiesen, in dem viele Entwurfsmuster und dazugehörige Beispielprobleme aufgelistet sind Definition In der Architektur wird ein Entwurfsmuster laut Christopher Alexander folgendermaßen umschrieben:"jedes Muster beschreibt ein in unserer Umwelt beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem, so dass Sie diese Lösung beliebig oft anwenden können, ohne sie jemals ein zweites Mal gleich auszuführen [...]" Ein Muster ist laut dieser Definition also zugleich eine Beschreibung von immer wiederkehrenden Problemen (z. B. die Frage, wann eine Bahnschranke geschlossen werden muss, wenn sich ein Zug nähert, und wie lange sie dann unten bleiben muss, damit auf der einen Seite die Möglichkeit eines Unfalls ausgeschlossen werden kann und auf der anderen Seite der Verkehrsfluss nicht unnötig lange aufgehalten wird), als auch die Kernlösung für diese Problemstellung (z. B. in Abhängigkeit von der Geschwindigkeit des Zuges und der erlaubten Fahrgeschwindigkeit der Autos müssen die Schranken f(x) Minuten vor Ankunft des Zuges geschlossen werden und dann noch g(x) Sekunden danach geschlossen bleiben). Was Alexander mit Türen und Wänden beschrieb und was in dem Beispiel mittels Zug, Schranke und Geschwindigkeit beschrieben wurde, beschreiben Informatiker mit Objekten und Schnittstellen. Allen gemeinsam ist, dass Problemlösungen für bestimmte Situationen gegeben werden. Etwas differenzierter betrachtet, besteht ein Entwurfsmuster aus vier grundlegenden Elementen (Abbildung 4.1): Der Mustername ist ein möglichst viel sagendes Wort, das ein Entwurfsproblem und seine Lösungen und Auswirkungen benennt. Der Problemabschnitt gibt Auskunft darüber, welches Problem adressiert wird, wann das Muster anzuwenden ist und was sein Kontext ist. Der Lösungsabschnitt enthält die Elemente, aus denen der Entwurf besteht. Es wird keine konkrete Implementierung angegeben, sondern vielmehr eine Schablone, die auf viele unterschiedliche (aber dennoch gleich geartete) Probleme angewendet werden kann. Der Konsequenzabschnitt listet die Konsequenzen der Musteranwendung auf. Diese beziehen sich z. B. häufig auf Speicherplatzverbrauch und Ausführungszeit oder auf die problematische Anwendbarkeit in bestimmten Programmiersprachen. 4.3 Beispiel: Entwurf der Dokumentstruktur eines Editors An dieser Stelle wird ein konkretes Entwurfsproblem vorgestellt, zu dessen Lösung ein passendes Entwurfsmuster verwendet wird.

56 42 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN Mustername Problemabschnitt Loesungsabschnitt Probleme gleicher Bauart Konsequenzen Abbildung 4.1: Schema eines Entwurfsmusters Angenommen es soll ein "What you see is what you get" Dokumenteditor entwickelt werden, der Grafiken und Text beliebig miteinander vermischt darstellen kann. Ein Teilproblem besteht in der Auswahl der internen Repräsentation von Dokumenten, also der Dokumentstruktur. Betrachtet man zuerst einmal die physische Struktur einer Seite (so wie sie ein Benutzer dieses Editors auf seinem Bildschirm zu sehen bekommt), dann ist es sicherlich erwünscht, dass optisch zusammengehörende Grafikelemente, wie z. B. ein Kreis und ein Rechteck, die eine Tasse von der Seite darstellen sollen, auch als ein Objekt behandelt werden können. Weiter könnte noch ein Name, also Text, auf der Tasse stehen oder aber eine weitere Grafik. Natürlich soll die so aus mehreren einzelnen grafischen Bausteinen zusammengesetzte Tasse je nach belieben des Anwenders als Ganzes eventuell verschoben werden können oder aber auch durch Bearbeiten der Substrukturen, wie der auf ihr enthaltenen Grafik, im Detail verändert werden können. Die interne Repräsentation der Dokumente des zu entwerfenden Editors soll genauso organisiert sein, wie die physische Repräsentation. Zunehmend komplexere Bausteine sollen aus elementaren Bausteinen mittels eines Kompositums, einem Verbindungskonstrukt, zusammengesetzt werden, also rekursiv komponiert werden. Diese entstehenden Grafiken sind alle vom gleichen Typ, werden also gleich behandelt. Beispielsweise sollen mehrere (einfache) Zeichen und eine Grafik zu einer Zeile zusammengefaßt werden. Diese Zeile und eventuell noch andere Zeilen werden dann zu einer Spalte zusammengefaßt, mehrere Spalten können danach zu einer Seite zusammengefaßt werden usw Entwurfsmuster "Kompositum" Es stellt sich nun die Frage, welches objektorientierte Verfahren man verwendet, um die gewünschte interne Repräsentation zu realisieren. Ohne an dieser Stelle zu erläutern, weshalb gerade dieses Entwurfsmuster ausgewählt wurde, wird im Folgenden das Entwurfsmuster mit dem Namen "Kompositum" vorgestellt, das das oben genannte Problem löst. Die allgemeine Struktur des Kompositionsmusters ist in Abbildung 4.3 visualisiert.

57 4.3. BEISPIEL: ENTWURF DER DOKUMENTSTRUKTUR EINES EDITORS 43 Spalte Zeile Zeile Tabelle Zeichen Zeichen Grafik Zeile Zeile Abbildung 4.2: Struktur einer Dokumentenseite Die Grundidee dieses Musters ist in der abstrakten Klasse "Komponente" zu sehen, die sowohl primitive Objekte (Blätter) als auch ihre Behälter (Komposita) darstellt. Sie deklariert Operationen, die spezifisch für einfache Komponenten-Objekte sind, wie auch Operationen, die allen zusammengesetzten Objekten gemeinsam sind. Die Unterklasse "Blatt" definiert die jeweiligen Operationen konkret. Das Kompositum definiert die Operationen derart, dass es die entsprechenden Operationen bei seinen Kindobjekten aufruft. Somit wird für den Klienten (Anwender) eine einheitliche Schnittstelle für den Zugriff auf einfache Elemente (Blätter) oder zusammengesetzte Elemente geschaffen. Klient Komponente Operation() FuegeHinzu(Komponente) Entferne(Komponente) GibKindobjekt(int) Blatt Operation() Kompositum Operation() FuegeHinzu(Komponente) Entferne(Komponente) GibKindobjekt(int) kindobjekte fuer alle g in kindobjekte g.operation(); Abbildung 4.3: Entwurfsmuster "Kompositum"

58 44 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN "Kompositum" angewandt auf das "Dokumentstrukturproblem" Um diese abstrakte Struktur des "Kompositionsmusters" anschaulicher darzustellen, soll es nun konkret auf das vorher beschriebene "Dokumentstrukturproblem" angewandt werden. Die Struktur ist in Abbildung 4 zu sehen und ist vom Prinzip identisch mit der allgemeinen Struktur des "Kompositionsmusters", nur das diesmal die Klassen und Operationen konkreter benannt sind (Die Klasse "Zeile" hat die gleichen Beziehungen wie "Spalte", sie wurden aber aus Gründen der Übersichtlichkeit zum Teil weggelassen). "Grafik" stellt Grafik Zeichne() FuegeHinzu(Grafik) Entferne(Grafik) GibKindobjekt(int) grafiken Linie Rechteck Text Zeichne() Zeichne() Zeichne() Zeile Zeichne() FuegeHinzu(Grafik) Entferne(Grafik) GibKindobjekt(int) Spalte Zeichne() FuegeHinzu(Grafik) Entferne(Grafik) GibKindobjekt(int) fuer alle g in grafiken g.zeichne() Abbildung 4.4: Konkrete Anwendung des "Kompositums" in diesem Fall die abstrakte Klasse dar (vorher Komponente), die Blätter haben die Namen "Linie", "Rechteck" und "Text", Komposita sind die "Zeile" und "Spalte". "Grafik" deklariert die Operation "Zeichne()", die auf primitive wie auch zusammengesetzte Objekte anwendbar ist und die Operationen "FuegeHinzu(Grafik)", "Entferne(Grafik)" und "GibKindobjekt(int)", die nur in den Komposita "Zeile" und "Spalte" definiert werden. "Linie", "Rechteck" und "Text" definieren jeweils nur die "Zeichne"-Operation. "Zeile" und "Spalte" implementieren "Zeichne()" derart, dass sie für alle enthaltenen Kindobjekte (z. B. ein Text und eine Linie) deren "Zeichne()"-Operation aufrufen. Jedes Blatt weiß in diesem Fall, wie und wo es sich zu zeichnen hat. 4.4 Beschreibung von Entwurfsmustern Die oben angegebene Struktur des Entwurfsmusters "Kompositum" ist nur ein Teil der vollständigen Beschreibung. Sicherlich ist sie ein zentraler Punkt der Beschreibung, jedoch nur dann sinnvoll anwendbar, wenn man schon weiß, welches Problem hier adressiert wird und welche Auswirkungen die Anwendung auf das restliche Programm haben kann. In

59 4.4. BESCHREIBUNG VON ENTWURFSMUSTERN 45 dem Buchvon Gamma [G + 97] werden folgende Punkte für eine vollständige Beschreibung eines Entwurfsmusters vorgeschlagen, die je nach Muster verschieden intensiv ausgeführt werden und eventuell sogar ganz wegfallen können. Im Folgenden werden die Punkte des einheitlichen Schemas zur Beschreibung von Entwurfsmuster nacheinander genannt und dann mit der (verkürzten) Beschreibung für das "Kompositum" veranschaulicht. 1. Name: Soll den wesentlichen Gehalt des Musters vermitteln. Beispiel: Kompositum 2. Zweck: Soll eine kurze Darstellung dessen sein, was das Entwurfsmuster macht und was sein Zweck ist. Beispiel: Fügt Objekte zu Baumstruktur zusammen und ermöglicht es dem Klienten, einzelne und zusammengefügte Objekte einheitlich zu behandeln. 3. Auch bekannt als: Gibt andere bekannte Namen für das Entwurfsmuster an. 4. Motivation: Beschreibt ein Entwurfsproblem und wie das Muster dieses Problem löst. Beispiel: Entwurfsproblem der internen Repräsentation von Dokumenten eine Editors, der mehrere Objekte zu einem Objekt der gleichen Art zusammenfügen kann. Lösung durch eine abstrakte Klasse, die Oberklasse von primitiven Objekten und Behältern ist. 5. Anwendbarkeit: Beschreibt, wann das Muster anzuwenden ist. Beispiel: Anzuwenden, wenn Teil-Ganzes-Hierarchien repräsentiert werden sollen und wenn Klienten den Unterschied zwischen einzelnen und zusammengesetzten Objekten nicht beachten sollen. 6. Struktur: Das Strukturdiagramm ist eine grafische Repräsentation der Klassen im Muster (mittels der Object-Modeling-Technique). Beispiel: Siehe oben. 7. Teilnehmer: Beschreibt die am Muster beteiligten Klassen und Objekte sowie ihre Zuständigkeiten. Beispiel: Die "Komponente" deklariert die Schnittstelle für Objekte in der zusammengefügten Struktur. 8. Interaktion: Beschreibt die Zusammenarbeit der Teilnehmer. Beispiel: Klienten verwenden die Kompositionsschnittstelle, um mit Objekten zu interagieren. Ist der Empfänger ein Blatt, wird die Anfrage direkt abgehandelt, ansonsten an die Kindobjekte weitergeleitet. 9. Konsequenzen: Nennt die Ergebnisse einer Anwendung des Musters und führt Vorund Nachteile auf. Beispiel: Der Klient wird vereinfacht, denn er kann Kompositionen und einzelne Objekte einheitlich behandeln. 10. Implementierung: Beschreibt die zu bedenkenden Punkte einer Implementation. Beispiel: Ordnung der Kindobjekte innerhalb eines zusammengesetzten Objektes. 11. Beispielcode: Liefert Codefragmente in einer bekannten Sprache. 12. Bekannte Verwendungen: Nennt Verwendungen des Musters in realen Systemen. Beispiel: RTL-Smalltalk-Übersetzer-Framework 13. Verwandte Muster: Erläutert, mit welchen anderen Mustern das Muster zusammenarbeiten kann. Beispiel: Iteratormuster

60 46 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN 4.5 Klassifikation von Entwurfsmustern Aufgrund der Vielzahl von unterschiedlichen Mustern ist es ratsam, ähnliche Muster unter einem Oberbegriff zusammenzufassen, damit beim Aufsuchen von neuen Mustern diese schneller gefunden werden können. Nach Gamma [G + 97] können die Muster nach den Aufgaben geordnet werden. Die Aufgaben geben wieder, was das betreffende Muster macht und sind in drei Bereiche aufgeteilt, den erzeugenden, den strukturorientierten und den verhaltensorientierten Aufgaben. ffl Erzeugungsmuster zeichnen sich durch den primären Prozess der Objekterzeugung aus. Ein Beispiel für diese Art von Muster ist das "Abstrakte Fabrik"-Muster, in dem eine Schnittstelle zum Erzeugen von Familien verwandter oder voneinander abhängiger Objekte realisiert wird. ffl Die Strukturmuster befassen sich mit der Zusammensetzung von Klassen und Objekten. Das Kompositionsmuster ist hierfür ein Beispiel. ffl In Verhaltensmustern geht es hauptsächlich um die Art und Weise, in der Klassen und Objekte zusammenarbeiten. Beispielsweise steht das "Zustands"-Muster für ein verhaltensorientiertes Muster, weil es einem Objekt ermöglicht, sein Verhalten zu ändern, wenn sein interner Zustand sich ändert. 4.6 Auswahl geeigneter Entwurfsmuster Suche Obwohl eine erste Klassifizierung der Entwurfsmuster vorgenommen wurde, ist es sicherlichnochnötig zu untersuchen, wie man zu einem gegebenen Entwurfsproblem das richtige Entwurfsmuster findet. Die folgenden Ansätze müssen nicht alle nacheinander ausgeführt werden, um zu einem Ergebnis zu gelangen, sie sind vielmehr Vorschläge, die selektiv zur Auswahl eines Musters benutzt werden können. ffl Der Zweckabschnitt des einheitlichen Formats der Entwurfsmuster gibt ein kurze Beschreibung der Aufgabe des Musters. Es ist sinnvoll zuerst einmal alle Zweckabschnitte (der in Frage kommenden) Muster quer zu lesen, um ein Gefühl dafür zu bekommen, was eventuell zu dem speziellen Entwurfsproblem passen könnte und um somit eine erste Selektion vornehmen zu können. ffl In [G + 97] werden auf Seite 13 die Beziehungen der Muster zueinander grafisch veranschaulicht. Diese übersichtliche Darstellung kann helfen, das richtige Muster bzw. die richtige Gruppe von Mustern zu finden. ffl Allgemein hilft es, die Unterschiede und die Ähnlichkeiten der Muster mit gleichen Aufgaben, also erzeugende, strukturorientierte und verhaltensorientierte Muster, genauer zu untersuchen. In [G + 97] wird in dem Katalog der Muster nach jedem Kapitel ein Vergleich der Muster vorgenommen.

61 4.7. FRAMEWORKS - MOTIVATION UND DEFINITION 47 ffl Damit ein Produkt möglichst gut wiederverwendet werden kann, muss im Vorfeld schon abgeschätzt werden, wo neue Anforderungen auftreten können und und wo existierende Anforderungen geändert werden können. Bestimmte Muster können helfen, Entwurfsrevisionen zu verhindern. Um beispielsweise eine Abhängigkeit von Hardware- und Softwareplattformen zu minimieren, sollte man die Muster "Abstrakte Fabrik" oder "Brücke" verwenden. Auf Seite 28 in [G + 97], wird eine Zuordnung von möglicher Entwurfsrevisionen und Mustern, die diese verhindern, vorgenommen. ffl Als letzter Punkt sei hier die Untersuchung dessen genannt, was in einem Entwurf variabel sein sollte. Bei dem "Kompositum" ist dies beispielsweise die Struktur und die Zusammensetzung eines Objektes Anwendung Nachdem im vorigen Abschnitt einige Ratschläge zur effektiven Auswahl eines Entwurfsmusters genannt wurden, soll nun beschrieben werden, wie dieses dann auch richtig anzuwenden ist, sofern man das erste Mal damit arbeitet. Folgende Punkte sollten nacheinander abgearbeitet werden, um eine optimale Anwendung zu erreichen. 1. Um sicherzustellen, dass das ausgewählte Muster das Richtige ist, sollte der Anwendbarkeits- und Konsequenzabschnitt nochmal aufmerksam gelesen werden. 2. Die Beziehungen der Klassen und Objekte untereinander sollten klar sein. Deshalb sollten der Struktur-, Teilnehmer- und Interaktionsabschnitt intensiv betrachtet werden. 3. Um eine Erleichterung bei der Implementierung des Musters zu erreichen, sollte der Beispielcode des Musters betrachtet werden. 4. Nun sollten Namen für die am Muster beteiligten Klassen und Objekte ausgewählt werden, die idealerweise die Teilnehmernamen in ihrem Namen enthalten. Beispielsweise sollte beim "Kompositum" die Klasse "Linie" den Namen "Linie-Blatt" erhalten. So findet man das Muster im eigenen Entwurf schnell wieder. 5. Jetzt sollte die Definition der Klassen erfolgen, indem die Schnittstellen deklariert werden, Vererbungsbeziehungen hergestellt werden und die Exemplarvariablen definiert werden. 6. Anwendungsspezifische Namen für Operationen im Muster müssen gefunden werden. 7. Zu guter Letzt müssen die Operationen implementiert werden. Hierbei ist es hilfreich, sich den Implementierungsabschnitt des Musters nochmals anzuschauen. 4.7 Frameworks - Motivation und Definition Mit Hilfe der objektorientierten Softwareentwicklung soll möglichst effizient wiederverwendbare Software entwickelt werden, wiederverwendbar in dem Sinne, dass bei neuen

62 48 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN aber ähnlichen Entwicklungen Code wiederverwendet werden kann. Frameworks nutzen ebenfalls die objektorientierte Softwareentwicklung, gehen aber noch einen Schritt weiter, denn sie unterstützen nicht nur die Code-Wiederverwendung, sondern auch die Analyse- Wiederverwendung, ermöglichen es also, die zu investierende Zeit für eine erneute Analyse eines Problems zu minimieren. R.E. Johnson definiert Frameworks folgendermaßen:"ein Framework ist eine Anzahl von Klassen, die ein abstraktes Design für Lösungen zu einer Familie verwandter Probleme enthalten [...]" Wie in Abbildung 4.5 zu sehen ist, besteht das eigentliche Framework nur aus einer zueinander in Beziehung stehender Menge von Klassen. In diesen Beziehungen spiegelt sich die Analyse der Probleme einer Problemklasse wieder, d.h. es wurden Gemeinsamkeiten der Problemklasse, die bei (fast) allen Problemen festgestellt wurden, durch bestimmte Beziehungen der Klassen im Framework abstrakt gelöst. Soll nun ein konkretes Problem der Problemklasse gelöst werden, kann eine spezielle Anwendung schnell und kostengünstig erstellt werden, indem nur die spezielle Funktionalität des Problems implementiert wird. Der Kontrollfluss geht vom Framework aus, indem dieser die Klassen der Applikation aufruft. Der Entwickler kann sich also auf die Besonderheiten seiner Applikation konzentrieren. Klasse Framework Klasse hat analysiert rufen auf Applikation Probleme gleicher Bauart Klasse Klasse loest konkretes Problem Abbildung 4.5: Schema eines Frameworks und einer Applikation 4.8 Klassifizierung von Frameworks Frameworks lassen sich nach der Art, wie eine konkrete Anwendung daraus erzeugt wird, klassifizieren. Es lassen sich hierbei drei Framework-Typen unterscheiden, White-BoxFrameworks, Black-Box Frameworks und Glass-Box Frameworks. ffl Die White-Box Frameworks zeichnen sich dadurch aus, dass in abgeleiteten Klassen bestimmte Methoden bzw. Beziehungen der Oberklassen überschrieben werden können. Somit wird anwendungsspezifische Funktionalität zum Framework hinzugefügt. Dieser Typ ist auf der einen Seite sehr flexibel, aber auf der anderen Seite

63 4.9. VORTEILE VON FRAMEWORKS 49 aufwendig in der Wiederverwendung, da detaillierte Kenntnisse über die Klassenstruktur notwendig sind. ffl Bei den Black-Box Frameworks steht eine Menge direkt zu benutzender Klassen zur Verfügung, deren Instanzen durch Übergabe geeigneter Parameter konfiguriert werden. Die innere Struktur des Frameworks bleibt dem Anwender vorenthalten. ffl Glass-BoxFrameworks sind eine Kombination aus den beiden vorher genannten Frameworks. Es können anwendungsspezifische Klassen mit einer Menge vorhandener Klassen kombiniert werden. Ein zweites Klassifizierungsmerkmal sind die Problembereiche, auf die sich die jeweiligen Frameworks beziehen. Hierbei sind wieder drei verschiedene Arten von Frameworks zu unterscheiden. ffl Application Frameworks unterstützen die Wiederverwendung von interaktiven Anwendungen wie z. B. einer GUI. ffl Als domänenspezifische Frameworks werden solche bezeichnet, die eine Lösung für ein bestimmtes Anwendungsgebiet liefern, wie z. B. dem Finanzwesen. ffl Support Frameworks unterstützen kleinere, speziellere Aufgaben, wie z. B. Dateizugriff. Sie werden häufig in den beiden vorigen Framework-Typen eingesetzt. 4.9 Vorteile von Frameworks Nachdem in der Motivation schon einige Vorteile von Frameworks aufgeführt wurden, sollen jetzt noch einmal detailliert die Punkte zusammengetragen werden, die für die Entwicklung eines solchen Softwarepaketes sprechen. ffl Ist ein solches Framework einmal entwickelt, kann relativ schnell eine konkrete Applikation geschrieben werden, so dass das Produkt schnell auf den Markt gelangen kann (Reduced time to market). ffl Wurden mehrere Applikationen mit einem Framework entwickelt, so unterscheiden sie sich nur in einem relativ kleinen Teil des Codes. Die Wartung der Programme beschränkt sich wegen des wahrscheinlich robusten Frameworks auch auf diese Teile, also kleinere, überschaubarere Programmstücke. Somit wird ein erheblicher Teil der Wartungskosten eingespart. ffl Wenn ein Framework für mehrere Applikationen benutzt wurde, können natürlich auch die alten Tests benutzt werden, um die korrekte Ausführung des Programms sicherzustellen. Es müssen nur die neuen Module und die Interaktionen zwischen diesen und dem Framework getestet werden. ffl Dadurch dass der Code des Frameworks über die Zeit mehrfach benutzt wird, verbessert er sich auch, da die Programmierer mehr Erfahrung im Umgang mit den Problemen der Problemdomäne bekommen. Es werden also Fehler beseitigt und somit wird es immer wahrscheinlicher, dass das Programm zufrieden stellend arbeitet.

64 50 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN ffl Implizit werden durch die Verwendung von Frameworks auch Standards eingeführt, da alle darauf arbeitenden Applikationen gewissen Anforderungen genügen müssen, um zu funktionieren. ffl Die Analyse der Problemdomäne ist bei Verwendung eines Frameworks nur einmal nötig, da das Ergebnis derselben im Framework festgehalten wird und danach von jedermann implizit verwendet werden kann. Es wird also ausgeschlossen, dass (sofern eine korrekte erste Analyse erfolgte) ein Entwickler einer Applikation für ein bestimmtes Problem, durch fehlendes Wissen über das Problem, falsche Abläufe programmiert. Ein Entwickler kann sich auf die Besonderheiten seines Problems konzentrieren. ffl Als letzter Vorteil sei hier aufgeführt, dass verschiedene Applikationen kompatibel zueinander sind, da sie in dem gleichen Rahmen entwickelt wurden Probleme bei der Frameworkentwicklung Bevor man mit der Frameworkentwicklung beginnt, sollte man sich darüber im klaren sein, welche Probleme eine solche Entwicklung mit sich bringt. ffl Aufgrund der intensiven Analyse der Probleme einer Problemdomäne ist ein immenser Zeitaufwand nötig, um den Framework zu entwickeln und dieser stellt nur den Rahmen für spätere Applikationen dar. Bis zur ersten Implementierung einer Applikation vergeht natürlich noch mehr Zeit, so dass bei einer möglichst schnell zu realisierenden Anwendung die herkömmliche Softwareentwicklung vorzuziehen ist. Jedoch sollte die zusätzliche Entwicklungszeit bei Frameworks als eine Investition in die Zukunft betrachten werden, die ihre Vorteile bei einer möglichst häufigen Anwendung des Frameworks für verschiedene Applikationen aufzeigt. ffl Für jemanden, der das Framework mitentwickelt hat, wird es sicherlich kein Problem darstellen, eine geeignete Applikation für ein Problem zu realisieren. Doch idealerweise sollte ein entwickelter Framework auch von Menschen genutzt werden, die nicht an seiner Entwicklung beteiligt waren. Diese benötigen sicherlich eine gewisse Einarbeitungszeit, um die Gedankengänge der Entwickler des Frameworks zu verstehen. ffl Dadurch dass durch das Framework der Rahmen für das Lösen einer Menge von Problemen geschaffen wird, müssen natürlich auch viele unterschiedliche Fälle abgefangen werden, die nicht unbedingt jedes Problem betreffen müssen, d. h. daß für einzelne Aplikationen ein gewisser Overhead anfällt, der zusätzlichen Speicher benötigt. ffl Als letzter Punkt sei nun noch aufgeführt, dass ein Problem bei der Integration bzw. Koppelung von Frameworks entstehen kann. Hiermit ist im Einzelnen die Verwendung von verschiedenen Programmiersprachen gemeint. Nicht ohne weiteres können Applikationen, die mit C++ entwickelt wurden, Objekte und Code, die

65 4.11. FRAMEWORKENTWICKLUNG 51 mit Smalltalk geschrieben wurden, wiederverwenden. Nur durch zusätzlichen Programmieraufwand (mit Hilfe von IDL) können diese Programmteile problemlos miteinander zusammenarbeiten. Des weiteren können unterschiedliche Versionen von verwendeten Compilern und unterschiedliche Plattformen zu Problemen bei der Zusammenarbeit führen Frameworkentwicklung An dieser Stelle wird nun der Entwicklungsprozess von objekt-orientierten Frameworks vorgestellt und mit einem Beispiel aus der Problemdomäne "Würfelspiele" verdeutlicht. Eine schematische Übersicht ist in Abbildung 4.6 zu sehen. Domaenen-Analyse Erfassen von Anforderungen und Analyse Framework -Design Applikation analysieren Design der Applikation Framework implementieren Test Applikation implementieren Abbildung 4.6: Frameworkentwicklung Die Domain-Analyse bezeichnet den Vorgang der Identifikation von Klassen und Objekten, die allen Applikationen einer gegebenen Problemdomäne gemeinsam sind. Es sollten nur Schlüsseleigenschaften betrachtet werden und nicht weiterführende Details. Bei der Untersuchung der Problemdomäne "Würfelspiele" im Sinne der Domain-Analyse ist es hilfreich, sich auf einige konkrete Würfelspiele zu konzentrieren und deren Gemeinsamkeiten herauszuarbeiten. In dieser Beispielanalyse werden Yatzy, Greed und Craps betrachtet. Allen gemeinsam ist, dass sie mit Würfeln gespielt werden, die sechs Seiten haben, dass Würfel geworfen werden können, dass es Spieler gibt, die an einem Spiel teilnehmen, dass es Regeln für jedes Spiel gibt usw. In der nächsten Phase werden die Anforderungen der konkreten Probleme erfasst, also beispielsweise, dass Yatzy mit fünf Würfeln gespielt wird und dass ein Yatzy-Spielblatt aus Einer, Zweier usw. besteht. Gleichermaßen wird dieses auch mit den anderen Beispielen durchgeführt. Als Ergebnis

66 52 KAPITEL 4. OO-ENTWURF MIT FRAMEWORKS UND ENTWURFSMUSTERN aus diesen beiden eben vorgestellten Phasen sollte man ein so genanntes "Analysis Object Model" erhalten, das Klassen und ihre Beziehungen untereinander beschreibt. Bei den Würfelspielen hätten wir also die Klasse "Spieler", die Oberklasse ist von "Yatzy- Spieler" und "Greed-Spieler". Dann gibt es die Klasse "Geldbörse" und die Beziehung von "Spieler" zu "Geldbörse" usw. In der nächsten Phase, dem Design des Frameworks, soll von einem konzeptionellen Blickwinkel aus die Grundlage für eine problemlose Implementierung des Frameworks geschaffen werden. Unter anderem müssen die benötigten Operationen bestimmt werden und festgelegt werden, wie die Kommunikationen zwischen den Objekten aussehen. Hierbei werden häufig Entwurfsmuster eingesetzt, um eine hohe Flexibilität des Frameworks zu erreichen. Beispielsweise ermöglicht es das Entwurfsmuster "Abstrakte Fabrik", die Instantiierung von konkreten Spielen vom Framework zu trennen. Ein Scheduler könnte einen Yatzy-Spieler instantiieren, ohne überhaupt zu wissen, dass es sich um einen solchen Spieler handelt. Hilfsmittel zur Identifizierung von Zusammenarbeitenden Klassen sind Interaktionsdiagramme. In dem abschließenden detaillierten Design werden Schnittstellen und Attribute des Frameworks vollständig definiert. Damit einhergehend erfolgt die Implementierung des Frameworks, also die Realisierung der benötigten Methoden, die endgültige Festlegung der benötigten Attribute usw. Natürlich muss wie bei allen Softwareprodukten ein Framework auch getestet werden, um so einen sicheren Rahmen für spätere Applikationen garantieren zu können Zusammenfassung - Entwurfsmuster und Frameworks Entwurfsmuster sind sehr gut geeignet als Einstieg in die objekt-orientierte Programmierung, da sie die Erfahrung anderer Programmierer widerspiegeln und somit eine gute Anleitung für unerfahrene Programmierer darstellen. Natürlich werden auch erfahrene Programmierer von der Benutzung von Entwurfsmustern profitieren können, da es für einen Einzelnen unmöglich ist, auf jedem Gebiet ein Experte zu sein. Durch einheitliche Kataloge kann für jedermann eine unverzichtbare Referenz entstehen, die eine gute objektorientierte Programmierung fördert. Es sei aber auch gesagt, dass eine effiziente Nutzung der Entwurfsmuster nur dann gegeben sein kann, wenn viele Muster miteinander verglichen werden, um die Eigenheiten der jeweiligen Muster zu erkennen und ein gewisses Gespür für das richtige Muster zu erlangen. Die Entwicklung eines Frameworks bietet sich dann an, wenn abzusehen ist, dass in Zukunft mehrere Probleme der gleichen Bauart gelöst werden müssen. Erst in der häufigen Wiederverwendung liegen die Stärken eines Frameworks. Frameworks sind sicherlich erst dann sinnvoll, wenn gewisse objektorientierte Techniken beherrscht werden. Es ist also ratsam, sich erst mit Entwurfsmustern zu beschäftigen, die dann ihren Einsatz in einem zu entwickelnden Framework finden können.

67 Kapitel 5 Objektorientierte Programmierung mit Softwarekomponenten Axel Wunsch Komponenten sind wiederverwendbare Softwarefragmente, die mit anderen Komponenten einfach zu neuen Anwendungen kombiniert werden können. Diese Seminarausarbeitung beschäftigt sich mit dem Thema der Entwicklung von Softwarekomponenten. Es wird zunächst erklärt, was Softwarekomponenten sind und wo sie Verwendung finden. Dann wird ausführlich auf die Komponententechnologie JavaBeans von JavaSoft eingegangen. Die Struktur einer JavaBean und die Kommunikation zwischen Beans sind wesentliche Punkte bei der Beschreibung von JavaBeans. Schließlich wird die Anwendung von Beans an einem Beispiel gezeigt. Abschließend werden dann noch einige Entwicklungswerkzeuge vorgestellt und ein Fazit gezogen. 53

68 54 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN 5.1 Einleitung Motivation Die Entwicklung von Software ist ein Vorgang, der in den letzten Jahren immer komplexer und teurer geworden ist. Hinzu kommt, dass die Programmierer immer weniger Zeit haben, um ein Programm fertigzustellen. Da ist die Überlegung naheliegend, einmal entwickelte Software für weitere Projekte wiederzuverwenden. Denn das würde nicht nur Zeit sparen, sondern auch die Qualität des Softwareproduktes erheblich verbessern, da die Entwickler sich verstärkt um andere Aspekte, wie beispielsweise das Design oder die Fehlerbeseitigung kümmern könnten Softwarekomponenten Daraufhin wurde das Konzept der Softwarekomponenten entwickelt. Komponenten sind wiederverwendbare Softwarefragmente, die leicht erweiterbar und miteinander kombinierbar sind. Dadurch wird den Entwicklern das Implementieren von neuen Programmen wesentlich erleichtert. Die Einführung der objektorientierten Sprachen war ein wichtiger Schritt in diese Richtung. Jedoch ist die Kapselung von Objekten kein Garant für die Wiederverwendbarkeit von Softwarefragmenten. Dafür sind strengere und einheitlichere Standards für die Schnittstellen und die Ereignisbehandlung von Softwarekomponenten erforderlich Aufbau der Ausarbeitung In dieser Ausarbeitung wird zunächst darauf eingegangen, wie Softwarekomponenten aufgebaut sind und welche grundlegenden Konzepte sie beinhalten. Darauf aufbauend wird erklärt, was eine JavaBean ist und wie die JavaBeans-API aufgebaut ist, wobei davon ausgegangen wird, dass der Leser grundlegende Kenntnisse von Java besitzt. Anschliessend werden die Eigenschaften einer Bean behandelt und es wird aufgezeigt, was bei der Entwicklung von JavaBeans zu beachten ist. Danach wird anhand eines Beispiels die Anwendung von JavaBeans demonstriert und es werden einige Werkzeuge, die die Entwicklung von Beans unterstützen, vorgestellt. Abschließend folgt dann ein Resumee, dass die Meinung des Autors zu der Thematik der Softwarekomponenten wiedergibt.

69 5.2. SOFTWAREKOMPONENTEN Softwarekomponenten Allgemeines Eine Komponente ist ein wiederverwendbares Stück Software, das leicht mit anderen " zusammengebaut werden kann, um auf diese Weise Anwendungen viel effizienter zu erstellen [Mor97b, Seite 26]. Es geht also darum, Softwarefragmente, die zu einem späteren Zeitpunkt erneut verwendet werden können, zu erkennen und sie geeignet zu kapseln. Dadurch kann der Softwareentwickler dann nach dem Baukastenprinzip verschiedene Komponenten einfach zusammenfügen und erhält, ohne sich über programmiertechnische Details Gedanken machen zu müssen, die gewünschte Anwendung. Somit braucht derentwickler nicht einmal tiefergehende Programmierkenntnisse zu besitzen, um ein neues Softwareprodukt erstellen zu können. Das klingt natürlich soweit ganz gut, allerdings stellt die Vielzahl der verschiedenen Prozessoren und Betriebssysteme ein nicht unerhebliches Problem bei der Vereinheitlichung der Softwarekomponenten dar. Außerdem möchte jeder Softwareentwickler gerne selbst die Programmiersprache für eine gegebene Aufgabenstellung auswählen können. Das ist ihm bei schon bestehenden Komponenten jedoch nicht möglich, da sie ja in einer bestimmten Programmiersprache entwickelt wurden. Daher sollte eine gute Komponententechnologie sowohl das Problem der Plattformabhängigkeit, als auch das Problem der Sprachabhängigkeit behandeln Komponentenmodelle Das Kernstück einer Technologie für Softwarekomponenten ist das dazugehörige Komponentenmodell. Dieses definiert die Architektur einer Komponente und ihre Funktionalität nach außen hin. Das heißt, das Komponentenmodell beschreibt, wie ein Entwickler auf die verschiedenen Funktionen einer Komponente zugreifen und mit ihnen arbeiten kann. Dabei werden zwei wesentliche Elemente eines Komponentenmodells unterschieden: Komponenten und Behälter. Der Komponententeil stellt sicher, dass die zu entwickelnden Komponenten nach einem bestimmten Muster erstellt werden, während der Behälterteil beschreibt, wie die Komponenten in einem übergeordneten Kontext zusammengefügt werden. Weiterhin umfasst ein komplettes Modell noch eine Reihe von Diensten, die eine Komponente unterstützen sollte: ffl Introspektion ffl Ereignisbehandlung ffl Persistenz ffl Layout ffl Anwendungsentwicklung ffl Verteilte Systeme

70 56 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Introspektion Die Introspektion stellt die Schnittstelle einer Komponente dar. Sie macht esalsomöglich, dass die Funktionalität nach außen hin sichtbar und somit für andere Komponenten verfügbar wird Ereignisbehandlung Die " Kommunikation zwischen Komponenten wird über Ereignisse realisiert. Ein Ereignis ist dabei etwas, dass innerhalb einer Komponente passiert, wie zum Beispiel die Änderung des Wertes einer Variable. Nun ist dieses Ereignis vielleicht wichtig für eine andere Komponente, die durch eine Nachricht entsprechend darauf reagieren kann. Diese Komponente ist dann ein Ereignisabhörer der Komponente, in der das Ereignis stattfand Persistenz Mit Hilfe der Persistenz wird festgelegt, wie der interne Zustand einer Softwarekomponente dauerhaft gespeichert und wiederhergestellt werden kann. Dabei muss beachtet werden, welche Werte wichtig für die Beschreibung des Zustands sind. Außerdem besteht die Möglichkeit eventuelle Beziehungen zu einem Behälter oder zu anderen Komponenten zu sichern Layout Die Unterstützung für das Layout betrifft nur sogenannte visuelle Komponenten. Das ist eine Komponente, die etwas sichtbar auf dem Bildschirm darstellt, wie zum Beispiel einen 'Button' einer grafischen Anwendung. Hier wird sinnvollerweise der Platzbedarf und die Position einer Komponente innerhalb eines Behälters festgehalten Unterstützung für die Anwendungsentwicklung Ein wichtiger Bestandteil einer Komponente ist die Unterstützung für Entwicklungswerkzeuge. Hierbei handelt es sich um Werkzeuge zur Bearbeitung einer Komponente, wobei diese Werkzeuge in der jeweiligen Softwarekomponente selbst enthalten sind. So kann man beispielsweise das Aussehen einer visuellen Komponente mit Hilfe eines Dialogfeldes ändern, das in dieser Komponente realisiert wurde. Damit ist sogar die Entwicklungsunterstützung in die Komponente integriert und gekapselt Unterstützung für verteilte Systeme Als Letztes sei noch die Unterstützung für verteilte Systeme erwähnt. Auf Grund der heutigen Popularität des Internets ist dieser Punkt nicht unwesentlich. Es gilt, die Probleme, die ein Netzwerk mit sich bringt, zu erkennen und zu behandeln. Gerade im Internet spielen Übertragungsfehler und Sicherheitsaspekte in der Datenübertragung eine große Rolle. Allerdings ist es abzuwägen, ob sich der Aufwand lohnt, da die Problembehandlung in verteilten Systemen eine recht komplexe Angelegenheit ist.

71 5.3. JAVABEANS JavaBeans Was ist JavaBeans? JavaBeans ist eine auf Java basierende, moderne Komponententechnologie. Die Entwickler von JavaBeans haben sich eine ehrgeizige Zielvorgabe gesetzt: " Einmal schreiben, überall laufen, überall wiederverwenden [Mor97b, Seite 40]. " Einmal schreiben soll in diesem Zusammenhang bedeuten, dass eine bereits vorhandene Bean ohne weiteres funktionell erweitert werden kann. Es ist also möglich, neue Methoden in eine Bean zu integrieren, ohne den ursprünglichen Code neu bearbeiten zu müssen. Dadurch wird den Entwicklern viel Arbeit und damit auch Zeit erspart. Mit " überall laufen ist die Plattformunabhängigkeit dieses Konzeptes gemeint. Diese Eigenschaft von JavaBeans wird durch die Tatsache erreicht, dass JavaBeans auf Java, das ja eine plattformunabhängige Programmiersprache ist, basiert. " überall wiederverwenden beziehtsich in diesem Zusammenhang auf das Wiederverwenden von Softwarefragmenten in verschiedenen Anwendungen. Dies stellt eine zentrale Rolle in der Philosophie der Softwarekomponententechnologie dar. Die Entwickler sollen also einmal geschriebene Beans für Softwareprojekte verwenden können, die in einem völlig anderen Szenario angesiedelt sind. All diese Anforderungen wurden in JavaBeans erfolgreich umgesetzt. Nun sind die Unterschiede zwischen Java und JavaBeans zwar nicht offensichtlich, aber dennoch sind sie wichtig für das Verständnis dieser Komponententechnologie. Zunächst einmal fällt auf, dass es Dinge wie Persistenz und Ereignisbehandlung auch bei Java gibt. Um genau zu sein, baut JavaBeans sogar auf den dafür geschriebenen Java-Klassen auf. Weiterhin ist es durchaus möglich, wiederverwendbare Software mit Java zu schreiben. Jedoch gibt es viel zu wenig Regeln, die eine einheitliche Struktur für eine wiederverwendbare Java-Klasse erzwingen würden. JavaBean-Komponenten müssen allerdings nach relativ strengen Konventionen, was die Ereignisbehandlung und die innere Struktur angeht, aufgebaut sein. Daher ist gewährleistet, dass eine JavaBean leicht mit anderen Beans kombiniert werden kann, ohne dass genaue Kenntnisse auf der Code-Ebene notwendig wären Struktur einer Bean Wie jede Datenstruktur einer objektorientierten Sprache, enthälteinejavabean Attribute und Methoden, mit denen man die Daten manipulieren kann. Die Attribute beschreiben vollständig den Zustand einer Bean. Bei den Methoden gibt es, wie bei Java, die Unterscheidung in private, geschützte und öffentliche Methoden. Die privaten Methoden können weder vererbt werden, noch kann man von außen auf sie zugreifen. Vererbung ist bei den geschützten Methoden jedoch möglich, allerdings kein Zugriff von außen. Die öffentlichen Methoden werden vererbt und sind von anderen Klassen zugänglich. Daher nehmen sie eine wichtige Rolle in der Struktur einer Bean ein, denn sie sind für die Kommunikation mit anderen Beans zuständig. Diese Methoden werden entsprechend ihrer Funktionalität gegliedert und stellen dann verschiedene Schnittstellen der Bean dar (siehe Abbildung 5.1).

72 58 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Abbildung 5.1: Struktur einer JavaBean Der Programmierer braucht nur die Schnittstellen einer Bean zu kennen, um sie in eine Anwendung integrieren zu können. Die inneren Datenstrukturen bleiben vor ihm verborgen, und es ist nicht erforderlich, dass er weiß, wie sie gestaltet sind JavaBeans-API Bei der konkreten Entwicklung von Beans ist es wichtig, die API von JavaBeans zu kennen, um die Komponententechnologie sinnvoll einsetzen zu können. Was ist eine API? API ist eine Abkürzung und steht für application programming interface. Es handelt sich also um eine Programmierschnittstelle für Anwendungen. JavaBeans ist also letztendlich eine Klassenbibliothek, die auf den Klassen von Java aufbaut. Dabei wird diese Bibliothek noch in weitere, kleinere APIs aufgeteilt, die den Diensten eines Komponentenmodells auffallend ähnlich sind: ffl Verwaltung von Eigenschaften ffl Introspektion ffl Ereignisbehandlung ffl Persistenz ffl Unterstützung für die Anwendungsentwicklung Verwaltung von Eigenschaften Dieser Teil der API legt fest, wie die Eigenschaften einer Bean strukturiert sind und wie sie verändert werden können. Eigenschaften sind benannte Attribute einer Bean, die ihren

73 5.3. JAVABEANS 59 Zustand widerspiegeln. Sie können in verschiedenen Umgebungen verwendet werden: Als Objektfelder in Scriptumgebungen, wie JavaScript oder VBScript, im Programm über öffentliche Zugriffsmethoden, visuell über Eigenschaftsblätter in Entwicklungswerkzeugen oder bei der persistenten Speicherung und Wiederherstellung einer Bean. Weiterhin muss es zu jeder Eigenschaft einer Bean eine Methode zum Schreiben eines Wertes und zum Auslesen des Wertes eines Attributes geben. Außerdem wird zwischen gebundenen Eigenschaften, indizierten Eigenschaften und Eigenschaften mit Constraints unterschieden Introspektion Durch die Introspektion wird die Funktionalität einer Bean nach außen hin offengelegt. Mit Hilfe der sogenannten Reflexionsdienste ist es möglich, dass Entwicklungswerkzeuge automatisch die Funktionalität einer Bean anhand der Methodennamen erkennen. Allerdings muss sich der Entwickler der Bean dabei an Standardkonventionen für Methodenund Attributnamen halten. Alternativ dazu kann er auch eine Informationsklasse erzeugen, in der er explizit die Methoden und die zugehörigen Eigenschaften auflistet. Zu einer modernen Entwicklungsumgebung gehört ein Introspector, der genau diese beiden Verfahren benutzt, um die Funktionalität einer Bean zu ermitteln Ereignisbehandlung Die Ereignisbehandlung des JavaBeans-API baut auf das schon vorhandene Ereignisbehandlungsmodell des Java-AWT-Paketes auf. Dabei wird eine Bean, die ein Ereignis erzeugt, als Ereignisquelle bezeichnet. Nun können mehrere Beans, die über dieses Ereignis informiert werden wollen, bei der Ereignisquelle registriert werden. Sie werden Ereignisabhörer genannt. Die Übermittlung eines Ereignisses zu den betroffenen Ereignisabhörern geschieht via Ereignisadaptern, die dafür Sorge tragen, dass die relevanten Informationen zu den richtigen Ereignisabhörern gelangen. Auch die Ereignisbehandlung wird im nächsten Kapitel noch näher erläutert Persistenz Bei der Speicherung und Wiederherstellung von Beans wird auf die Serialisierung der Java-API zurückgegriffen. Dabei werden alle Eigenschaften einer Bean, die für die Beschreibung des Zustands notwendig sind, in einen Byte-Strom umgewandelt und können so einfach weggespeichert werden. Es gibt jedoch auch die Möglichkeit, eigene Methoden zum Speichern und Wiederherstellen von JavaBeans-Komponenten zu erstellen Unterstützung für die Anwendungsentwicklung Zu guter Letzt gibt es noch einen Teil des JavaBeans-API, der die Anwendungsentwicklung unterstützt. Hierbei handelt es sich um die Möglichkeit, Beans visuell den eigenen Vorstellungen anzupassen. Einerseits kann man Eigenschaften einer Bean über Eigenschaftsblätter verändern, die ähnlich wie Formulare aufgebaut sind und somit eine schnelle Anpassung der Bean ermöglichen. Andererseits kann über Customizer auf die

74 60 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Bean-Eigenschaften zugegriffen werden. Customizer ähneln den sogenannten " Wizards. Wizards verwenden mehrschrittige Fragebögen, um Informationen vom Anwender zu sammeln. 5.4 Bean-Eigenschaften Die Bean-Eigenschaften sind ein zentraler Bestandteil der JavaBeans-Technologie. Die Eigenschaften bilden den Datenteil einer JavaBean. Sie beschreiben also den internen Zustand einer Bean. Die einzige Möglichkeit von außen auf diese Eigenschaften zuzugreifen, geschieht über Zugriffsmethoden. Wie vorhin schon erläutert wurde, gibt es Lese- und Schreibmethoden um die Werte der Attribute zu ändern. Wichtig hierbei ist, dass andere Beans oder Anwendungen nicht direkt die Werte der Bean verändern können. Somit wird verhindert, dass sich der interne Zustand einer Bean ändert, ohne dass die Bean von dieser Änderung informiert wird. Es wird dabei von der Erhaltung der Konsistenz gesprochen. Weiterhin gibt es drei verschiedene Typen von Eigenschaften: Indizierte Eigenschaften, gebundene Eigenschaften und Eigenschaften mit Constraints. Indizierte Eigenschaften sind nichts weiter als die von Java her bekannten Arrays. Um auf einzelne Elemente einer indizierten Eigenschaft zuzugreifen, werden ganzzahlige Indizes verwendet Gebundene Eigenschaften Wesentlich mehr Funktionalität bieten die gebundenen Eigenschaften. ändert sich der Wert einer gebundenen Eigenschaft, so möchten vielleicht andere Beans oder Anwendungen davon informiert werden. Dazu müssen sie als Ereignisabhörer bei der Bean registriert sein. Das erfolgt über die folgende Methode: addpropertylistener(propertylistener l); ändert sich nun der Wert der gebundenen Eigenschaft, so erzeugt die zugehörige Bean ein PropertyChangeEvent, das Informationen über die veränderte Eigenschaft sowie ihren alten und neuen Wert enthält. Dieses Objekt wird nun an den PropertyChangeListener weitergegeben, der wiederum das PropertyChangeEvent-Objekt an alle registrierten Ereignisabhörer weiterreicht. Abbildung 5.2 verdeutlicht diesen Vorgang.

75 5.4. BEAN-EIGENSCHAFTEN 61 Abbildung 5.2: Die innere Arbeitsweise einer gebundenen Eigenschaft Eigenschaften mit Constraints Eigenschaften mit Constraints verhalten sich ähnlich wie gebundene Eigenschaften. Auch hier können Ereignisabhörer registriert werden, die bei Veränderung der Eigenschaft mit Constraints informiert werden möchten. Zum Anmelden als Ereignisabhörer dient folgende Methode: addvetoablechangelistener(vetoablechangelistener l); Tritt nun eine Änderung der Eigenschaft mit Constraints ein, so wird von der Bean zunächst wieder ein PropertyChangeEvent erzeugt. Dieses wird über den Vetoable- ChangeListener an die eigentlichen Ereignisabhörer weitergeleitet. Nun kann der Ereignisabhörer jedoch entscheiden, ob er die Änderung zulässt oder nicht. Verweigert er die Änderung, so muss er eine PropertyVetoException zurückliefern und die Bean, in der die Änderung stattfand, muss das Attribut auf den alten Wert zurücksetzen. Diese Ereignisbehandlung wird in Abbildung 5.3 noch einmal grafisch dargestellt. Abbildung 5.3: Die Arbeitsweise einer Eigenschaft mit Constraints Verwendung von Eigenschaften Wie vorhin schon erwähnt wurde, können Bean-Eigenschaften auf verschiedene Arten verwendet werden. In Scriptumgebungen wie JavaScript oder VBScript wird auf die Eigenschaften über Instanzvariablen von Bean-Objekten zugegriffen: thing.numberoflives = 12; Es sieht zwar so aus, als würde die Variable numberoflives direkt geändert werden, doch tatsächlich wird intern die Schreibmethode dieser Eigenschaft aufgerufen. In Programmen hingegen werden die Eigenschaften, wie es die JavaBeans-API vorsieht, ganz normal über die entsprechenden Lese- und Schreibmethoden angesprochen. Außerdem besteht die

76 62 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Möglichkeit, Eigenschaften visuell zu verwenden. Das geschieht über die schon erwähnten Eigenschaftsblätter und Customizer. Auch hier werden zum Bearbeiten der Eigenschaften lediglich die bekannten Zugriffsmethoden benutzt. Die letzte Art der Verwendung von Eigenschaften ist die Persistenz. Denn da die Eigenschaften ja den Zustand einer Bean darstellen, gilt es, genau diese abzuspeichern und wiederherzustellen, um Persistenz zu erreichen. Dies geschieht natürlich auch über die Zugriffsmethoden der JavaBean. 5.5 JavaBeans in der Praxis Entwicklung von JavaBeans Ein sorgfältiges Design ist beim Entwickeln von Software immer ein wichtiger Punkt. Bei JavaBeans nimmt das Design jedoch einen besonderen Stellenwert ein. Es geht ja schließlich darum, wiederverwendbare Softwarekomponenten zu erstellen. Das heißt, der Entwickler muss sich überlegen, wofür die Bean verwendet wird und vor allem auch wie die Bean in zukünftigen Projekten verwendet werden könnte. Also sollte er auch berücksichtigen, dass die entwickelte JavaBean leicht erweiterbar ist. Zunächst sollten die Eigenschaften einer Bean festgelegt werden. Sie repräsentieren bekanntlich den Datenteil und damit den Zustand einer Bean. Sind die Eigenschaften gefunden, sollte entschieden werden, ob gebundene Eigenschaften oder Eigenschaften mit Constraints unter ihnen sind, da die Implementierung der Methoden davon abhängt. Doch bevor dies geschieht, sollte überlegt werden, welche öffentlichen Methoden die Bean anderen Komponenten zur Verfügung stellen soll. Hierbei kann mit der Definition der Zugriffsmethoden begonnen werden. Dann müssen eventuell noch Methoden eingerichtet werden, die es erlauben, Ereignisabhörer an- bzw. abzumelden. Schließlich können noch individuelle Methoden, die als sinnvoll erachtet werden, hinzugefügt werden. Der letzte Designabschnitt deckt die Ereignisbehandlung ab. Nun kann entschieden werden, welche Beans Ereignisse erzeugen können und wie auf diese reagiert werden soll. Bei selbstentwickelten Ereignistypen ist es außerdem wichtig, für jeden Typ eine entsprechende Klasse zu implementieren. Nun kann mit der Implementierung der Bean begonnen werden. Ist auch diese Phase abgeschlossen, so möchte der Entwickler die Bean sicherlich gerne testen. Dafür bietet sich die BeanBox an, die Teil des JavaBeans Development Kit (BDK) ist. Nachdem die Bean ausgiebig getestet wurde, kann sie gepackt werden, damit andere Entwickler sie verwenden können. Beim Packen werden aus den Bean-Klassen sogenannte JAR-Dateien (Java Archive) gebildet, auf die direkt von anderen Beans oder Anwendungen zugegriffen werden kann Anwendung von JavaBeans Die Verwendung von JavaBeans geschieht in zwei Schritten: Als erstes werden die Beans den individuellen Wünschen des Entwicklers angepasst. Es handelt sich dabei hauptsächlich um die Gestaltung des Layouts und die Positionierung von Beans innerhalb eines Behälters. Das gilt natürlich nur für visuelle Komponenten. Dann werden die angepassten Beans miteinander verknüpft. Das bedeutet, dass Ereignisse, die eine Bean verschickt, mit

77 5.5. JAVABEANS IN DER PRAXIS 63 öffentlichen Methoden anderer Beans verbunden werden. Schon ist die Anwendung fertig. Der Entwickler kann diese beiden Schritte auf konventionellem Wege erledigen, in dem er einen Editor benutzt und den Programmcode " von Hand erzeugt. Er hat jedoch auch die Möglichkeit, diese Arbeit mit einem visuellen Entwicklungswerkzeug wie der BeanBox zu tätigen, was wesentlich komfortabler ist. Die BeanBox besteht aus einem Behälter, der später die zu testenden Beans enthält, und der ToolBox, die eine Liste von bereits fertigen Beans darstellt. In Abbildung 5.4 ist außerdem noch das Eigenschaftsblatt des BeanBox-Behälters zu sehen, über das Hintergrundfarbe, Schriftart, etc. des Behälters geändert werden kann. Abbildung 5.4: Die BeanBox Zum Testen der BeanBox wurde ein Button und der Java-Juggler per Drag&Drop in den BeanBox-Behälter gezogen. Nun wird das Eigenschaftsblatt des Jugglers angezeigt. Hier kann beispielsweise die Schnelligkeit der Animation, sowie die Hinter- und Vordergrundfarbe eingestellt werden (Abbildung 5.5).

78 64 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Abbildung 5.5: Drag&Drop in der BeanBox Nachdem der Button selektiert wurde, kann über das Edit-Menü ein Ereignis des Buttons ausgewählt werden. In diesem Fall ist es das Ereignis buttonpushed. Dann kann das Ereignis mit einem Ziel verbunden werden. Im Beispiel ist das die öffentliche Methode startjuggling der Juggler-Bean, wie in Abbildung 5.6 zu sehen ist.

79 5.6. ABSCHLIEßENDE ANMERKUNGEN 65 Abbildung 5.6: Verbinden von Beans in der BeanBox Nun kann die fertige Anwendung durch Klicken auf den Button getestet werden. Vorher muss allerdings noch im View-Menü der Test-Modus der BeanBox aktiviert werden Werkzeuge für JavaBeans Die eben beschriebene BeanBox ist wahrscheinlich das einfachste Entwicklungswerkzeug für JavaBeans. Es gibt allerdings auch wesentlich komplexere Werkzeuge mit einem größerem Funktionsumfang. Visual Café beispielsweise ist ein Entwicklungswerkzeug, das von Symantec vertrieben wird. Es bietet die volle Unterstützung für die visuelle Entwicklung von Beans, Applets und Anwendungen. Dabei lässt es sich ähnlich einfach wie die Bean- Box bedienen. Ein weiteres Werkzeug ist der JBuilder von Borland. Interessanterweise sind Teile des JBuilders als Beans realisiert worden. Dies zeigt noch einmal die Flexibilität der JavaBeans-Technologie. Auch SunSoft ist mit dem Java Workshop vertreten. Wie zu erwarten, ist dieses Werkzeug komplett in Java programmiert worden. Daher gibt es dieses Entwicklungswerkzeug auch für unterschiedliche Plattformen wie Solaris, Windows oder Macintosh. Weiterhin sind noch Visual Age von IBM und Mojo von Penumbra Software erwähnenswert. 5.6 Abschließende Anmerkungen Das Wiederverwenden von Softwarefragmenten ist mit Sicherheit ein guter Ansatz, um die Entwicklung von Anwendungen effizienter zu gestalten. JavaBeans leistet hierbei einen guten Dienst. Denn durch das klare und eindeutige Konzept, das hinter den JavaBeans-Softwarekomponenten steckt, wird das Entwickeln eigener Beans einfach gehalten. Auch der

80 66 KAPITEL 5. OO-PROGRAMMIERUNG MIT SOFTWAREKOMPONENTEN Austausch von Beans zwischen verschiedenen Entwicklern stellt kein großes Problem dar, da ein Einarbeiten in den Quellcode weitestgehend entfällt. Somit werden beim Entwickeln von Software kostbare Ressourcen eingespart, die an anderer Stelle, wie beispielsweise der ergonomischen Gestaltung einer Benutzungsoberfläche, verwendet werden können. Im Endeffekt kommen all diese Vorteile dem Benutzer zu Gute. Und schließlich ist er es, der mit dem Programm arbeiten will oder muss.

81 Kapitel 6 Client/Server-Programmierung mit Java Michael Hülsmann Die Client/Server-Programmierung ist das Standard-Programmiermodell für vernetzte Rechner: ein Client sendet eine Anfrage an einen entfernten Server, der bearbeitet die Anfrage und sendet eine Antwort zurück. Diese Seminarausarbeitung beschäftigt sich mit der Entwicklung von verteilten Applikationen, die in der Programmiersprache Java geschrieben werden. Im Wesentlichen wird dabei auf Sockets, RMI und CORBA eingegangen. Die Grundlagen dieser Konzepte werden kurz dargestellt. Als Ausgangspunkt für diese Konzepte dient die Client/Server- Architektur, als das Progammiermodell für verteilte Anwendungen in Netzwerken. Um einen praktischen Bezug zu erhalten, wird anhand von Beispielen die Umsetzung dieser Konzepte deutlich gemacht. Die Beispiele sind einfach gehalten, um ein Nachvollziehen der Vorgehensweise zu erleichtern. 67

82 68 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA 6.1 Einleitung Motivation Mit der zunehmenden globalen Vernetzung entsteht der Wunsch, digitale Bibliotheken für jedermann über das Internet nutzbar zu machen. Und bei einer Nutzung über das Internet bietet sich Java als Programmiersprache wegen seiner Plattformunabhängigkeit an. Es empfiehlt sich daher, mit den gängigen Techniken zur Entwicklung von Netzwerk- Applikation vertraut zu machen. Dies erleichtert später im Anwendungsfall die Wahl des zu verwendenden Verfahrens Client/Server-Architektur Die Client/Server-Architektur hat sich als Standard-Programmiermodell für vernetzte Rechner durchgesetzt: ein Client sendet eine Anfrage an einen entfernten Server, der Server bearbeitet die Anfrage und sendet unter bestimmten Voraussetzungen eine Antwort zurück (Abb. 6.1). Auf dem Server-Rechner werden verschiedene Dienste angeboten, die von den entfernten Clients genutzt werden können. Jeder dieser Dienste wird auf Server-Seite durch ein Serverprogramm repräsentiert, auf Client-Seite durch ein entsprechendes Clientprogramm. Bekommt der Server eine Anfrage von einem Client, muss er prüfen, ob der Client für den Zugriff auf den Dienst berechtigt ist. Man klassifiziert die Dienste nach öffentlich zugänglichen Informationsdiensten und nicht öffentlichen Diensten. Öffentliche Dienste sind das WWW, anonymes FTP oder Newsgroups. Diese öffentlichen Dienste sind für jeden Client nutzbar und bedürfen keiner speziellen Authentifizierung. Nicht öffentliche Dienste (z.b. Telnet, ssh) werden dann verwendet, wenn es um Zugriff auf private Benutzer- oder Firmendaten geht. Der Server darf solche Daten nur den Besitzern zugänglich machen und muss daher bei jeder Anfrage die Berechtigung des Clients überprüfen. Abbildung 6.1: Client/Server-Architektur

83 6.1. EINLEITUNG Aufbau des Artikels In dieser Ausarbeitung wird auf 3 Konzepte der Netzwerkprogrammierung in Java eingegangen: ffl Java und Sockets (nur TCP-Sockets) ffl Java-RMI ffl Java undcorba Die Vorgehensweise ist so, dass zunächst jeweils die Grundlagen dieser Konzepte behandelt werden. Anschließend wird jedes dieser drei Konzepte anhand eines Implementierungsbeispiels vorgestellt. In diesem Beispiel gibt es lediglich zwei relevante Methoden: ffl Der Server erhält vom Client einen Text ( " Hallo Server! ) und gibt diesen auf seiner Konsole aus. ffl Der Client empfängt vom Server einen Text ( " Hallo Client! ) und gibt diesen auf seiner Konsole aus. Die Implementierungsbeispiele haben in allen drei Konzepten die gleiche Funktionalität, um eine leichtere Vergleichbarkeit zu ermöglichen. In den Kapiteln zu Java-RMI und Java und Corba wird jeweils ein Entwicklungszyklus dargestellt, da die Vorgehensweise in dem Fall etwas aufwendiger als bei fleinfachenfi Java-Applikationen über Sockets ist. Die Beispielimplementierungen werden daher nicht gesondert aufgeführt, sondern als Teilschritt im Entwicklungszyklus beschrieben.

84 70 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA 6.2 Java und Sockets Was sind Sockets? Das Java-Tutorial[sun99] definiert ein Socket wie folgt: fla socket is one endpoint of a two-way communication link between two programs running on the network. A socket is bound to a port number so that the TCP layer can identify the application that data is destined to be sent.fi Frei übersetzt heißt das: ein Socket stellt einen flkommunikationsendpunktfi einer fl2- Wege-Kommunikationsverbindungfi zweier Programme dar. Der Client hat ein Socket und der Server hat ein Socket. Das Socket ist an eine Portnummer gebunden, damit das Transport Control Protocol (TCP) die Applikation identifizieren kann, die die Daten versenden will. Bei der Verbindung über Sockets stellt der Client eine Anfrage an den Server über einen bestimmten (dem Client natürlich bekannten) Port (Abb. 6.2). Der Server fllauschtfi an diesem Port und erwartet Anfragen von Clients. Akzeptiert der Server die Anfrage eines Clients, wird ein neuer Socket für die Kommunikation zwischen Server und Client hergestellt. Diese Verbindung läuft allerdings nicht über den Port, mit dem der Server das Netz nach Client-Anfragen abhört. Es wird ein freier Port gewählt, so dass der Server weiterhin die Möglichkeit hat, Client-Anfragen zu bearbeiten. Diese Vorgehensweise ist notwendig, damit der Server weiter nach Anfragen fllauschenfi kann, während er mit dem Client kommuniziert. Abbildung 6.2: Sockets

85 6.2. JAVA UND SOCKETS Die Kommunikationsklassen ffl Socket.class Diese Klasse stellt die Verbindung zum Server her und ist für die Datenübertragung zuständig. Daten werden per Stream-Objekt übertragen. Dementsprechend gibt es die Methoden getinputstream() und getoutputstream(). Außerdem gibt es Methoden zum Schließen eines Streams und zum Feststellen von Portnummern und Internet-Adressen der beteiligten Client- und Server-Programme. ffl ServerSocket.class Diese Klasse wartet auf Verbindungsanforderungen von Clients. Über die Methode accept() erzeugt sie einen Socket für die Kommunikation mit einem Client. Die Methode accept() stellt einen echten Block dar. Die Programmausführung (im aktuellen Thread) wird solange gestoppt, bis ein Client Kontakt mit dem Server aufnimmt. Des weiteren gibt es Methoden zu Netzwerkeinstellungen, mit denen z.b. fltimeoutsfi eingestellt werden können.

86 72 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA Beispielimplementierung Das folgende Beispiel zeigt eine Server-Implementierung mit der im Vorwort (Kapitel 6.1.1) beschriebenen Funktionalität. /* Die relevanten Klassen fuer Sockets sind in java.net enthalten und muessen daher importiert werden. Da die Kommunikation stream-basiert ist, wird java.io ebenfalls benoetigt. */ import java.net.*; import java.io.*; public class Server public static void main(string[] args) try /* Erzeugen eines ServerSockets zum "Abhoeren" des Netzes nach Client-Anfragen (hier auf Port 2000).*/ ServerSocket server = new ServerSocket(2000); // Das Socket fuer die Verbindung zum Client Socket client; /* accept() wartet solange, bis sich ein Client mit dem Server verbindet. */ while ((client = server.accept())!= null) /* Empfangen ueber den Input-Stream des Clients-Sockets */ BufferedReader vomclient = new BufferedReader (new InputStreamReader(client.getInputStream())); // Daten vom Client ausgeben System.out.println("Client: "+vomclient.readline()); // Senden ueber den Output-Stream des Client-Sockets PrintWriter zumclient = new PrintWriter(client.getOutputStream(), true); } // Daten zum Client schicken zumclient.println("hallo Client!"); } } // Falls Fehler auftreten (SocketException, IOException) } catch (Exception e) System.err.println("Fehler: "+e);}

87 6.2. JAVA UND SOCKETS 73 Die Implementierung eines Clients ist ähnlich einfach: import java.net.*; import java.io.*; public class Client public static void main(string[] args) try /* Hiermit wird die Verbindung zum Server hergestellt. Als Uebergabeparameter wird Netzadresse und die Portnummer des Servers benoetigt. */ Socket server = new Socket("localhost", 2000); // Senden ueber den Output-Stream des Server-Sockets PrintWriter zumserver = new PrintWriter(server.getOutputStream(), true); // Daten zum Server senden zumserver.println("hallo Server!"); // Empfangen ueber den Input-Stream des Server-Sockets BufferedReader vomserver = new BufferedReader (new InputStreamReader(server.getInputStream())); // Daten vom Server ausgeben System.out.println ("Server: "+vomserver.readline()); } } } catch (Exception e) System.err.println("Fehler: "+e);}

88 74 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA 6.3 Java-RMI Grundlagen RMI steht für Remote Method Invocation und das beschreibt auch schon, worum es eigentlich geht: dem Aufrufen von entfernten Methoden bzw. dem Aufruf von Methoden eines entfernten Objekts. Es handelt sich um eine Implementierung des Remote-Procedure- Call-Paradigmas (RPC). Java-RMI ist CORBA sehr ähnlich, es ist jedoch eine reine Java- Lösung. Bei RMI definiert ein Server Objekte, die die Clients über das Netz benutzen können. Dem Client erscheint es so, als ob die Objekte lokal in der Virtuellen Maschine (VM) vorhanden wären. Welche Methoden und Objekte des Servers ein Client benutzen darf, wird in dem sogenannten Remote-Interface definiert. Bei Methodenaufrufen können sowohl primitive als auch komplexe Objekte übergeben werden. Damit komplexe Objekte übergeben werden können, müssen sie serializable sein. Durch die Serialization wird möglich, dass Objekte in einen Stream verwandelt werden können, welcher dann versandt wird. Der Empfänger kann diesen Stream wieder in das ursprüngliche Objekt umwandeln. Um die Sicherheitsbelange kümmert sich der Security Manager. Dieser sollte sowohl beim Client als auch beim Server geladen werden. Ansonsten ist es nicht möglich, fremden Code über das Netz zu laden. Der Security Manager sorgt dafür, dass nur Code von erlaubten Hosts geladen wird. Der Class Loader ist für das Laden von Klassen aus dem Netz zuständig. Dies kann notwendig sein, wenn bestimmter Code nicht lokal vorhanden ist und von entfernten Rechner geladen werden muss. Es wird z.b. beim Starten einer Client-Applikation eine URL angeben, die angibt, wo der benötige Code zu finden ist. Auf Server-Seite gibt es einen Naming Service, der Objekte mit lesbaren Namen assoziiert. Dabei werden mittels der Befehle bind() bzw. rebind() Server-Objekten Namen zugeordnet. Clients können mit dem Namen per lookup() bei der Registry anfragen und erhalten eine Referenz auf das entfernte Server-Objekt zurück. Die Registry implementiert den Naming Service (siehe oben). Sie läuft auf einem festgelegten Port und muss immer vor dem Server gestartet werden. Wenn der Server gestartet wird, kontaktiert er die Registry und trägt sich in diese ein. Ein Client kann nun bei der Registry anfragen und eine Referenz auf ein Server-Objekt erhalten. Bei RMI kommunizieren Client und Server nicht direkt miteinander. Dem Client steht eine Instanz des sogenannten Client-Stubs zur Verfügung. Diese repräsentiert das entfernte Server-Objekt und ist in der VM des Clients vorhanden. Ruft der Client also eine entfernte Methode auf, wird in Wirklichkeit die Methode des entsprechenden Stub-Objekts aufgerufen. Das Stub-Objekt kümmert sich um das Einpacken der Parameter, erzeugt einen Binärstrom, den es über das Netz an das Server-Skeleton sendet(das Skeleton-Objekt ist das Gegenstück zum Stub-Objekt auf der Server-Seite). Diesen Vorgang nennt man marshalling. Beim Skeleton-Objekt angekommen, wird der Binärstrom wieder in einen Methodenaufruf übersetzt und an das Server-Objekt übergeben(unmarshalling). Die Rückgabewerte des Server-Objekt werden dann vom Skeleton-Objekt flge-marshalledfi, zurück an das Stub-Objekt gesendet, flge-unmarshalledfi und letztendlich an den Client zurückgegeben.

89 6.3. JAVA-RMI Entwicklungszyklus Abbildung 6.3: RMI - Entwicklungszyklus Die Entwicklung einer verteilten Anwendung mit RMI (Abb. 6.3) gliedert sich wie folgt: 1. Die Definition des Remote-Interface. Hier wird festgelegt, welche Methoden und Parameter der Client benutzen darf. Für das gewählte Beispiel sieht das so aus: import java.rmi.*; public interface ServerInterface extends Remote public void sende(string text) throws RemoteException; public String empfange() throws RemoteException; } Es ist zu beachten, dass das Remote-Interface von dem Interface Remote abgeleitet werden muss, welche in dem Package java.rmi enthalten ist. Jede Methode muss eine RemoteException werfen können, da beim Aufruf entfernter Methoden Netzfehler auftreten können. 2. Die Implementierung der Server-Klasse. Ein Server erbt immer von der Klasse UnicastRemoteObject (ist in java.rmi.server enthalten) und enthält den wichtigen Zusatz...implements ServerInterface. Hier werden also auch die in dem Remote-Interface definierten Methoden implementiert. Das Beispiel: import java.rmi.*; import java.rmi.server.*;

90 76 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA public class Server extends UnicastRemoteObject implements ServerInterface // Der Konstruktor fuer den Server public Server() throws RemoteException super();} // Die Implementierung der Methoden aus dem Remote-Interface public void sende(string text) throws RemoteException System.out.println("Client: "+text); } public String empfange() throws RemoteException return "Hallo Client!"; } public static void main(string[] args) try // Laden des Security Managers System.setSecurityManager(new RMISecurityManager()); // Erzeugen einer neuen Server-Instanz Server server = new Server(); } } // Hiermit traegt sich der Server in der // Registry ein. Naming.rebind("// /RMI_Server", server); System.out.println ("Server ist mit Registry verbunden!"); } catch (Exception e) System.err.println("Fehler: "+e);} 3. Kompilieren des Remote-Interface und der Serverklasse mittels javac. Für das Beispiel: javac ServerInterface.java javac Server.java 4. Zum Erzeugen der Client-Stubs und Server-Skeletons muss die Serverklasse mit dem RMI-Compiler umgwandelt werden: rmic <Serverklasse> Für das Beispiel wäre der Befehl: rmic Server Es wird kein Datei-Suffix angegeben.

91 6.3. JAVA-RMI Implementierung des Clients. Der Clients verwendet die Methoden des Remote- Interface. Auch hier ist wieder zu beachten, dass das Package java.rmi importiert wird. Entsprechend sieht das Beispiel aus: import java.rmi.*; public class Client public static void main(string[] args) try // Laden des Security Managers System.setSecurityManager(new RMISecurityManager()); // Adresse und Name unseres Servers String url = "// /RMI_Server"; // Bei Registry des Servers anmelden und nach dem // Server fragen. Bei Erfolg wird eine Referenz // auf den Remote-Server zurueckgegeben. ServerInterface server = (ServerInterface) Naming.lookup(url); // Aufruf von Server-Methoden server.sende("hallo Server!"); System.out.println("Server: "+server.empfange()); } } } // Falls Fehler auftreten catch (Exception e) System.err.println("Fehler: "+e);} 6. Kompilieren des Clients mit javac. Der Befehl für das Beispiel: javac Client.java 7. Die reine Entwicklung der verteilten Anwendung ist nun abgeschlossen.

92 78 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA Ablauf einer RMI-Applikation Im folgenden wird beschrieben, wie eine RMI-Applikation zu starten ist und wie ein Methodenaufruf vom Client an den Server vorgenommen wird. Abbildung 6.4 illustriert diesen Ablauf. Abbildung 6.4: 1. Zuerst wird auf dem Host des Servers die Registry gestartet. Standardmäßig wird Port 1099 benutzt. Der notwendige Befehl ist für Unix: rmiregistry [port]& Unter Windows erfolgt der Aufruf so: start rmiregistry [port] Damit ist die Registry gestartet und bereit, Eintragungen von Servern zuzulassen. 2. Start des Servers mit: java [-Djava.rmi.server.codebase=<URL Serverklassen>] [-Djava.rmi.server.hostname=<Adresse des Server-Hosts>] [-Djava.security.policy=<Policy-Datei>] <Servername> Über codebase wird angegeben, wo sich die Klassen des Servers befinden (i.d.r. werden die Klassen auf einem WWW-Server liegen). hostname gibt den Rechner an, auf dem der Server gestartet wird. In der Policy-Datei kann dem Security Manager mitgeteilt werden, was erlaubt ist und was nicht. Es kann z.b. gesteuert werden, auf welchem Port Verbindungen akzeptiert werden oder ob auf bestimmte Dateien

93 6.3. JAVA-RMI 79 Leserechte gewährt werden. (Mehr zum Thema Policy-Files gibt es unter [sun98]) Die Policy-Datei wird unter Java 1.2 zwingend benötigt, ansonsten läßt der Server sich nicht starten. Unter Java 1.1 kann sie weggelassen werden. Hier ein kleines Beispiel einer Policy-Datei, bei der alles erlaubt ist: grant // Allow everything for now permission java.security.allpermission; }; Für den Beispiel-Fall ist als Servername " Server einzusetzen. 3. Der Server trägt sich nun mittels rebind() in Registry ein. Dabei wird ein sprechender Name für den Server und eine Referenz auf ihn übergeben. 4. Start des Clients: java [-Djava.rmi.server.codebase=<URL Serverklassen>] [-Djava.security.policy=<Policy-Datei>] <Clientname> Für das Beispiel Clientname durch " Client ersetzen. 5. Der Client fragt mit lookup() bei der Registry Server-Hosts nach und bekommt eine Referenz auf den Remote-Server übergeben. Eventuell nicht vorhandener Stub-Code wird dabei vom entfernten Rechner zur VM des Clients übertragen. 6. Der Client ruft eine Methode auf dem Server auf. Real geschieht dies jedoch auf dem Client-Stub. Mittels Marshalling und Unmarshalling gelangt der Methodenaufruf zum Server. Die Rückgabewerte werden auf dieselbe Art wieder an Client zurückgegeben.

94 80 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA 6.4 Java und CORBA Grundlagen CORBA steht für Common Object Request Broker Architecture und ist in erster Linie eine Spezifikation, die die Interaktion von Objekten in verteilten und heterogenen Systemen beschreibt. CORBA wird von der Object Management Group[omg] (OMG) betreut und gepflegt. Bei der OMG handelt es sich um ein Konsortium aus mehreren hundert Firmen, das Standards für die Entwicklung von OO-Technologien entwickelt. CORBA zeichnet sich durch eine sprachen- und plattformunabhängige Spezifikation der Objekte mittels der Interface Definition Language (IDL) aus. IDL erlaubt es, alle CORBA-Objekte auf die gleiche Art zu beschreiben. Für alle gängigen Programmiersprachen sind Tools vorhanden, die eine in IDL beschriebene Schnittstelle in die jeweilige Programmiersprache übersetzen. Die Kommunikation läuft bei CORBA über den sogenannten Object Request Broker (ORB). Der ORB ist ein Object-Bus, über den CORBA-Objecte miteinander interagieren (lokal oder zwischen entfernten Rechnern). Der ORB ist dafür zuständig, die entsprechende Implementierung der CORBA-Objekts zu finden, es auf Anfragen vorzubereiten, Anfragen korrekt an das Objekt zu übergeben und die Antworten an den Client zurückzusenden. Um einen Dienst in Anspruch zu nehmen, erhält der Client eine Referenz auf ein CORBA-Server-Objekt. Der Client ist damit in Lage, Methodenaufrufe an das Server- Objekt zu übergeben, als wäre es auf dem eigenen Rechner. Einen ORB für Java kann man von verschiedenen kommerziellen Anbietern beziehen. Mit JDK 1.2 liefert Sun kostenlos einen sogenannten Lightweight-ORB mit, der auch in den Beispielimplementierungen dieses Dokuments genutzt wurde. Als Netzwerkprotokoll wird das vom CORBA-Standard spezifizierte Internet Inter- ORB Protocol (IIOP) eingesetzt, welches auf TCP/IP aufsetzt. CORBA-Anwendungen, die ORB's von unterschiedlichen Anbietern verwenden, können so miteinander kommunizieren, unabhängig von dem jeweiligen darunterliegenden System Interface Definition Language (IDL) Mithilfe der IDL werden die vom Server zur Verfügung gestellten Operationen und Attribute beschrieben. Es ist vergleichbar mit dem Remote-Interface bei Java-RMI, mit dem entscheidenen Unterschied, dass es sprachenunabhängig ist. Mit der IDL werden keine Implementierungsdetails festgelegt, es handelt sich lediglich um eine Schnittstellenbeschreibung, was auch für das RMI-Interface gilt. Die strenge Trennung der Schnittstellen von ihrer Implementierung ermöglicht eine Einbindung von bestehenden Softwaresystemen in CORBA. Der Syntax von IDL ist an die Programmiersprache C/C++ angelehnt. Mit einem IDL- Compiler wird die Schnittstelle in die jeweilige gewünschte Programmiersprache übersetzt. Dabei werden IDL-Statements in Statements der Programmiersprache flgemapptfi (z.b. in Java: interface <name>! public interface <name>). Desweiteren werden die Stubund Skeleton-Klassen (analog Java-RMI) und für CORBA benötige Hilfsklassen erzeugt.

95 6.4. JAVA UND CORBA 81 Der IDL-Compiler des JDK von Sun nennt sich flidltojavafi. Beim Übersetzen eines IDL-Interface legt er ein Verzeichnis mit allen relevanten Java-Dateien an. Es handelt sich dabei nur um Java-Quellcodes in Form eines Package, die anschließend noch mit dem javac übersetzt werden müssen Der Ablauf eines Methodenaufrufs Wie läuft ein Methodenaufruf bei CORBA intern ab? Abbildung 6.5 zeigt die im wesentlichen beteiligten Komponenten, wenn ein Client eine Anfrage an einen Server sendet. Ein Client hat eine Referenz auf ein entferntes Server-Objekt. Durch einen Methodenaufruf auf dem Server-Objekt wird zunächst die entsprechende Stub-Methode auf der lokalen VM gerufen, die die entfernte Server-Methode repräsentiert. Diese Stub-Methode übersetzt die Anfrage in einen Binärstrom (marshalling) und übergibt diesen an den ORB. Der ORB sorgt nun dafür, das dieser Methodenaufruf mittels IIOP zum Server gelangt. Ist der Binärstrom am Server angekommen, wird er mithilfe des Skeleton-Codes wieder in einen Methodenaufruf übersetzt (unmarshalling) und an die Server-Klasse übergeben. Die Methode wird jetzt auf dem Server ausgeführt und das Ergebnis wird über den Skeleton- Code wieder in einen Binärstrom umgewandelt (marshalling) und via ORB zurück an den Client geschickt. Abbildung 6.5: CORBA - Methodenaufruf

96 82 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA Corba - Entwicklungszyklus Der Entwicklungszyklus einer CORBA-Anwendung in Java (Abb. 6.6) läßt sich wie Java- RMI in typische Teilschritte untergliedern: Abbildung 6.6: CORBA - Entwicklungszyklus 1. Erstellen des IDL-Interface Die vom Server angebotenen Dienste werden in einer IDL-Datei beschrieben. Sie enthält alle Methoden, die ein Client rufen kann, mögliche Ausnahmen (Exceptions), die auftreten können, sowie alle erforderlichen Ein- und Ausgabeparameter. Der Dateiname endet mit dem Suffix fl.idlfi. Die IDL-Datei für das Beispiel: module TestCorba interface Test void sende(in string text); string empfange(); }; }; 2. Mit dem IDL-Compiler werden die für Java relevanten Klassen erzeugt (Interface, Stubs, Skeletons,...). Hierfür wird der Befehl idltojava <IDL-Datei>.idl aufgerufen. Pro angegebenen Modul wird ein Java-Package mit dem Modulnamen erzeugt, in dem die erzeugten Java-Klassen abgelegt werden. 3. Implementierung des Servers. In diesem Schritt wird die Server-Anwendung realisiert. Der IDL-Compiler hat aus dem IDL-Interface ein entsprechendes Java- Interface generiert, das nun implementiert werden muss. Die implementierende Klasse wird von _<interface>implbase abgeleitet (das Beispiel: _TestImplBase), die vom IDL-Compiler erzeugt wurde.

97 6.4. JAVA UND CORBA 83 // Dieses Package hat der IDL-Compiler erzeugt. import TestCorba.*; // Diese Packages werden fuer alle CORBA-Anwendungen // benoetigt. import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; import org.omg.corba.*; public class Server public static void main(string[] args) try /* Eine Instanz des ORB's wird erzeugt. Sowohl Client als auch Server benoetigen den ORB. */ ORB orb = ORB.init(args, null); /* Erzeugen einer Servant-Instanz. Der Servant enthaelt die Implementierungen fuer die in der Schnittstelle beschriebenen Methoden. */ Servant testref = new Servant(); // Der Servant wird dem ORB bekannt gemacht orb.connect(testref); /* Zugriff auf den Naming Service vorbereiten. Eine Referenz auf das Server-Objekt soll dort abgelegt werden (vergleichbar mit der Registry bei RMI). Der Naming Service ist bei CORBA wie ein Baum aufgebaut, daher wird nicht nur der Name des Server-Objektes abgelegt, sondern es kann auch ein ganzer Pfad hinterlegt werden (muss aber nicht). */ org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path[] = nc}; // Damit wird Server beim Naming Service eingetragen ncref.rebind(path, testref); /* Der Server wartet auf Anfragen eines Clients, sofern er nicht durch das System gestoppt wird. */ java.lang.object sync = new java.lang.object(); synchronized(sync) sync.wait(); }

98 84 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA } } // Abfangen von Fehlern, die im Netz auftreten koennen } catch (Exception e) System.err.println("Fehler: "+e);} /* Der Servant enthaelt die eigentliche Implentierung der Methoden aus dem IDL-Interface. Die _TestImplBase ist eine vom IDL-Compiler generierte Klasse, die die notwendigen CORBA-Implementierungen zur Kommunikation mit ORB enthaelt. */ class Servant extends _TestImplBase public void sende(string text) System.out.println("Client: "+text);} public String empfange() return "Hallo Client!";} } 4. Die Implementierung des Clients. import TestCorba.*; import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; import org.omg.corba.*; public class Client public static void main(string[] args) try // Der ORB ORB orb = ORB.init(args, null); /* Nutzen des Naming Service zum Auffinden des Servers. (Entspricht dem Naming.lookup() bei RMI) */ org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path[] = nc}; Test testref = TestHelper.narrow(ncRef.resolve(path)); // Aufruf der Server-Methoden testref.sende("hallo Server!"); System.out.println("Server: "+testref.empfange()); // Moegliche Netzwerkfehler abfangen

99 6.4. JAVA UND CORBA 85 } } } catch (Exception e) System.err.println("Fehler: "+e);} 5. Jetzt müssen alle erzeugten Klassen kompiliert (javac) werden. Es empfiehlt sich, zunächst das vom IDL-Compiler generierte Package zu kompilieren, da es sowohl für den Server als auch für den Client relevante Klassen enthält. Anschließend werden Server und Client kompiliert. 6. Abschließend kommen wir zum Starten der CORBA-Applikation. Zunächst müssen den Naming Service starten (vergleichbar mit der Registry bei RMI): tnameserv [-ORBInitialPort nameserverport] Ohne Angabe der Portnummer startet der Naming Service auf Port 900. Als nächstes wird der Server gestartet: java <Servername> [-ORBInitialHost nameserverhost] [-ORBInitialPort nameserverport] ORBInitialHost gibt an, auf welchem Rechner sich der Naming Service befindet. Wird diese Angabe nicht gemacht, nimmt der Server an, dass der Naming Service sich auf dem lokalen Rechner befindet. Des weiteren kann die Portnummer des Naming Service spezifiziert werden. Der Client wird genauso gestartet: java <Clientname> [-ORBInitialHost nameserverhost] [-ORBInitialPort nameserverport] Für das Standardbeispiel muss Servername durch Server und Clientname durch " Client ersetzt werden. "

100 86 KAPITEL 6. CLIENT/SERVER-PROGRAMMIERUNG MIT JAVA 6.5 Abschließende Anmerkungen Welches Konzept nun letztendlich zur Realisierung einer Netzwerk-Applikation verwendet wird, hängt natürlich sehr stark von den Anforderungen ab, die sie erfüllen soll: Muss die Applikation mit Programmen anderer Plattformen kommunizieren? Welche Rolle spielt die Performance bei Netzwerk-Anwendungen (Zwischen RMI und CORBA war in dieser Hinsicht und mit den verwendeten Beispielen kein Unterschied auszumachen.)? Welche Rolle spielt die Sicherheit bei Übertragungen im Netzwerk? Wie komplex ist die Anwendung? Es kommt also auf den Einzelfall an. Zur weiteren Vertiefung der Thematik empfehlen sich die folgenden Bücher bzw. Artikel: ffl The Java Tutorial [sun99] ffl Java professionell [WK99] ffl Java Examples in a Nutshell [Fla98] In den oben aufgeführten Büchern werden RMI und CORBA relativ kurz abgehandelt. Wer weitergehende Informationen, insbesondere zu CORBA, sucht, sollte neben der Homepage der OMG [omg] auch diese Quellen ansehen: ffl Client/Server Programming With Java and CORBA [OH] ffl CORBA meets Java [Mor97a] ffl A Detailed Comparison of CORBA, DCOM and Java/RMI [Raj98]

101 Kapitel 7 Datenbankanbindung für Internet-Informationssysteme Andre Rolfs Diese Ausarbeitung soll einen Überblick über Internet-basierte Datenbank-Anbindungen geben. Es wird erläutert, was eine Datenbank ist, wie man sie generell ansteuert und wie man sie über das Internet zugreifbar macht. Dazu werden unterschiedliche Techniken vorgestellt, die sich zwar nicht rein auf die Datenbank-Anbindung beziehen, aber oft dafür benutzt werden. Dazu gehören CGI, ASP, Java-Applets und -Servlets und speziell ODBC und JDBC, wobei die zwei zuletzt genannten Techniken ausschließlich auf die Anbindung von Datenbanken ausgerichtet sind. Zum Schluss wird auf die Anbindung von Datenbanken über proprietäre Schnittstellen im Gegensatz zu freien Schnittstellen eingegangen. 87

102 7.1 Einführung In dieser Ausarbeitung wird zuerst auf Datenbanken und deren generelle Anbindung über das Internet eingegangen. Danach werden gegenübergestellt CGI und ASP, ODBC und JDBC und dann Java-Applets und Java-Servlets besprochen. Zum Schluss wird auf die Idee der proprietären Datenbank-Anbindung eingegangen. 7.2 Motivation für Datenbank-Anbindungen Die Einschränkungen des One-Way-Download Wenn man Informationen im Internet bereitstellen möchte, gibt es die Möglichkeit, sie in Web-Seiten zu codieren, so dass derjenige, der diese Informationen sucht, sie auf diesen Seiten nachlesen kann. Man spricht hier von statischen Seiten oder dem One-Way- Download. Diese Seiten können nur geladen und eingesehen werden. Eine Suchfunktion über Dokumente oder innerhalb der Dokumente kann so nicht realisiert werden, da nur die Dokumente selbst zur Verfügung gestellt werden. Es findet keine Interaktion zwischen dem Benutzer (in den Folien der User) und den Web-Seiten statt und es können keine Informationen über den Benutzer persistent gespeichert werden, die ihm das Arbeiten mit den Seiten erleichtern würden. Dazu gehört z.b. die formelle Begrüßung, das informieren über neue Informationen, die ihn speziell interessieren könnten oder das Speichern seiner Adresse, um ihn auch außerhalb der Web-Seiten informieren zu können. Die Pflege dieser Seiten ist gerade bei großen Datenmengen sehr schwierig, da man keine Möglichkeit hat, Informationen gezielt einzufügen, veraltete Informationen herauszunehmen, oder die Informationen automatisch zu indizieren, um eine Suche über den Index zu realisieren. Um diese Probleme zu lösen werden Datenbanken verwendet. Im nächsten Abschnitt wird die Funktionsweise einer generellen SQL-Datenbank und deren Anbindung über das Internet vorgestellt Datenbanken Eine Datenbank wird zur Speicherung und zum Abfragen von Informationen verwendet. Bei einer Datenbank wird unterschieden zwischen dem Datenbank-Schema, welches die notwendigen Tabellen enthält, nach deren Schema Informationen in der Datenbank abgelegt werden und den Informationen, die in der Datenbank gespeichert werden. Datenbank- Schema und Informationen zusammen werden als Datenbank verstanden. Die wichtigsten Funktionen einer Datenbank für den Benutzer sind das Einstellen, Suchen, Abfragen und Löschen von Informationen. Das Erstellen des Datenbank-Schemas ist die Aufgabe des Administrators der Datenbank, welcher mit der Pflege der Datenbank betraut ist. Um mit einer Datenbank zu arbeiten benötigt man eine Sprache, durch die der Benutzer mit der Datenbank kommunizieren kann. SQL (Structured Query Language) hat sich als Standard-Sprache für diesen Zweck etabliert, weswegen mittlerweile jede gängige Datenbank per SQL angesprochen werden kann. Sofern der Benutzer an dem Rechner arbeitet,

103 auf dem die Datenbank installiert ist, benötigt er keine weiteren Hilfsmittel, da die Datenbank ihm Eingabe-Möglichkeiten für die oben genannten Funktionen bietet. Soll dem Benutzer über das Internet Zugriff auf die Datenbank zur Verfügung gestellt werden, so benötigt man eine Anbindungstechnik, die den Zugriff über Web-Seiten auf eine Datenbank ermöglicht. Dabei handelt es sich um mehrere Software-Schnittstellen, über die eine Datenbank angesprochen werden kann. Diese Schnittstellen und wie man über sie auf die Datenbank zugreifen kann, wird in den folgenden Abschnitten erläutert. 7.3 Ein Modell einer Datenbank-Anbindung über das Internet Sofern es sich um eine Datenbank handelt, deren Daten einer breiten Masse an Benutzern zur Verfügung gestellt werden sollen, bietet es sich an, die Datenbank über das Internet verfügbar zu machen. In diesem Fall surft der Benutzer, der auf die Datenbank zugreifen möchte den Web-Server an, der mit der Datenbank verbunden ist und stellt seine Anfrage an den Web-Server. Der Web-Server kommuniziert dann mit der Datenbank und schickt die ermittelten Informationen der Datenbank wieder an den Browser des Benutzers. Web-Server Datenbank Die klassische Datenbank-Anbindung mit CGI CGI - Common Gateway Interface CGI (Common Gateway Interface) ist eine Schnittstelle zwischen einem Web-Server und dem darunter liegendem Betriebssystem. CGI ermöglicht es, Programme über das Betriebssystem zu starten, die beliebige Aufgaben erfüllen können und unabhängig vom Web-Server sind, also nur vom Betriebssystem abhängen, d.h. sie müssen für das Betriebssystem compiliert werden und setzen je nach Betriebssystem entsprechende Compiler voraus. Davon abgesehen bestehen keine Beeinschränkungen in der Wahl der Programme, die durch die CGI-Schnittstelle angesprochen werden sollen. Der Zweck eines CGI-Programms kann beliebig sein, es könnte z.b. die aktuelle Uhrzeit ermittelt werden, um dem Benutzer einer Internet-Seite einen guten Tag oder Abend zu wünschen, oder um Hintergrundinformationen über den Benutzer zu speichern. In unserem Interesse ist die Anbindung einer Datenbank, auf die der Benutzer über das Internet zugreifen kann. [WHAa]

104 Wie wird eine Datenbank über CGI angesprochen Die Anbindung des Web-Servers an die Schnittstelle der Datenbank wurde bis vor kurzem generell über das Common-Gateway-Interface (CGI) realisiert. Bei CGI werden vom Web- Server im Normalfall Pearl- oder C-Programme mit der Anfrage des Benutzers aufgerufen, die dann die Anfrage in die Datenbanksprache umsetzen, die Anfrage an die Datenbank stellen, dann die Antwort der Datenbank erhalten und die Web-Seiten mit den gewünschten Informationen erstellen. Diese Seiten werden nach der Fertigstellung vom Web-Server bereitgestellt und auf dem Browser des Benutzers angezeigt. Common Gateway Interface Web-Server Datenbank Vor- und Nachteile von CGI Die Vorteile von CGI liegen in der großen Menge an schon bestehenden Pearl- und C- Programmen, die viele generelle Problemstellungen lösen und daher keine Kosten in der Erstellung mehr verursachen, höchstens in der Anpassung an spezielle Probleme. Da CGI die älteste Technologie zum interagieren zwischen Web-Server und anderen Programmen darstellt, ist sie auch am weitesten verbreitet und sehr ausgereift. Es gibt viele Programmierer, die sich mit den Konzepten auskennen. Nachteilig ist allerdings, dass für jede Anfrage an den Web-Server ein neues CGI-Programm gestartet wird, da diese Technologie nicht multithreaded arbeitet. Das bedeutet, dass der Server, auf dem die CGI-Programme laufen, bei vielen gleichzeitigen Anfragen schnell ausgelastet sein kann. CGI-Programme werden außerdem direkt auf dem Betriebssystem ausgeführt, weswegen sie bei falscher Handhabung ein Sicherheitsrisiko für den Server darstellen, weil ein Absturz des Rechners durch Seiteneffekte der Programme nicht völlig ausgeschlossen werden kann ASP - Active Server Pages Eine Alternative zu CGI stellen die Active Server Pages von Microsoft dar. Sie agieren genauso wie CGI-Programme, mit dem Unterschied, dass der Programm-Code direkt in die HTML-Datei eingefügt wird und zur Laufzeit interpretiert wird. [Micb] [ASPa] Mit ASP kann man Active X Skripts und Active X Server Komponenten ansteuern. Die Syntax von ASP ist eine einer Variation von Visual Basic. Es gibt mittlerweile mehrere Programme, die bei der Erstellung von ASP-Programmen hilfreich sind, wie z.b. Microsoft VBScript oder Microsoft Visual InterDev.[ASPe] [ASPd] [ASPc] [ASPb]

105 Vor- und Nachteile von ASP Auch bei ASP ist der Vorteil, dass es mittlerweile viele Programmierer aufgrund der Verbreitung von Windows gibt, die sich damit auskennen und schon Programme für Standard- Probleme existieren. Jedoch lassen sich ASP-Programme nur auf Microsoft Web-Servern ausführen, laut dem PC Magazine nur auf dem Microsoft Information Server, und das bedeutet zwangsläufig, dass der Server auf einem Microsoft Betriebssystem, wie z.b. Windows NT, laufen muss Reichen CGI und ASP aus? CGI- und ASP-Programme müssen bei der Anbindung an die Datenbank-Software an die jeweilige Schnittstelle der entsprechenden Datenbank angepasst sein. Das bedeutet, die Software läuft nur mit der Datenbank zusammen, für deren Schnittstelle die Software geschrieben wurde. Soll die Datenbank ausgetauscht werden, z.b. My-SQL gegen Oracle 8i, so müssen auch die CGI-Programme angepasst werden. Um diese Abhängigkeit aufzulösen wurde die Datenbank-Schnittstelle ODBC entwickelt. ODBC ist eine standardisierte Datenbank-Schnittstelle, die auf die proprietäre Schnittstelle einer Datenbank aufsetzt, was bei der Nutzung von ODBC die Anpassung der CGI- oder ASP-Programme überflüssig macht. 7.4 ODBC und JDBC Open Database Connectivity (ODBC) und Java Database Connectivity (JDBC) sind Application Program Interfaces (API s), die zwischen den Web-Server und die Datenbank- Software geschaltet sind, also Datenbank-Schnittstellen. Auf diese Schnittstellen kann, wie schon beschrieben, mit CGI- oder ASP-Programmen zugegriffen werden. Der generelle Vorteil der Verwendung von Standard-Schnittstellen liegt darin, dass die Anbindung an die Datenbank-Software mit CGI oder ASP nur noch einmal codiert werden muss und bei einer Änderung der Datenbank nur das entsprechende ODBC- bzw. JDBC-Paket ausgetauscht werden muss. Bei den bekannteren Datenbanken sind diese Datenbank- Schnittstellen mit im Lieferumfang enthalten bzw. leicht erhältlich ODBC - Open Database Connectivity User@Browser ODBC Web-Server ODBC-Driver Datenbank

106 Bei ODBC handelt sichumeinedatenbank-schnittstelle, welche über einen Driver mit der Datenbank kommuniziert. Wird die Datenbank gegen eine andere ersetzt, so muss nur der Driver ausgetauscht werden, die CGI- oder ASP-Programme brauchen nichtverändert werden, weil sie nur mit dem Standard-Interface des ODBC-API kommunizieren. Entwickelt wurde der ODBC-Standard von der SQL Access Group und der erste Einsatz dieser Software fand unter Windows statt. [WHAb] Mittlerweile hat sich dieser Standard auch unter Unix, Macintosh und OS/2 Plattformen durchgesetzt. Damit der Benutzer an die Datenbank, welche über das Internet erreichbar ist, anfragen über eine Internet-Seite stellen kann, schickt der Browser des Benutzer die Anfrage an den Web-Server, welcher diese dann an die ODBC-Schnittstelle weiterleitet, die wiederum über den Driver mit der Datenbank kommuniziert. Da sich die Programmiersprache Java aufgrund der Portabilität der Programme und der Möglichkeit, sie für Aufgaben im Internet in Form von Applets und Servlets einzusetzen (wird in Kapitel 5 erläutert), durchgesetzt hat, wird im nächsten Abschnitt auf die JDBC- Schnittstelle eingegangen, die eine Schnittstelle zwischen einem Java-Programm und der ODBC-Schnittstelle darstellt JDBC - Java Database Connectivity User@Browser JDBC-ODBC-Bridge ODBC Web-Server ODBC - Driver ODBC- Interface Datenbank JDBC ist eine Datenbank-Schnittstelle, die in der Programmiersprache Java implementiert ist. Die JDBC-Schnittstelle kommuniziert mit der ODBC-Schnittstelle, wobei anstelle von CGI- oder ASP-Routinen Java-Applets bzw. Java-Servlets verwendet werden, die auf einer JVM (Java Virtual Machine) laufen. Die Anbindung von JDBC an ODBC wird durch die JDBC-ODBC-Driver-Bridge realisiert, in der die Anfragen, die an die JDBC-Schnittstelle gestellt werden zu ODBC-Statements übersetzt und weitergereicht werden. [Suna] Der Vorteil von JDBC ist, dass die Anfrage-Programme auf einer JVM ablaufen, d.h. wenn gefährliche Seiteneffekte auftreten kann zwar die JVM abstürzen, aber es muss nicht zwangsläufig das Betriebssystem des Servers abstürzen. 7.5 Java : Applets und Servlets Java-Applets und -Servlets sind Java-Programme, die auf einer JVM ablaufen und in unserem Zusammenhang die Alternative zu CGI und ASP darstellen.

107 7.5.1 Java-Applets Applet Request Client und Datenbank interagieren über Applet Web-Server Datenbank Java-Applets sind Java-Programme, die die Klasse Applet erweitern. Sie können jedem beliebigen Zweck dienen und man kann sie über das Internet auf einen Client-Rechner laden und dort auf einer JVM (Java Virtual Machine) ausführen. Sie können vielseitig eingesetzt werden, z.b. für die Realisierung der Datenbank-anfragen, oder für das Visualisieren der Daten am Browser des Benutzers. Da sie auf dem Client-Rechner ausgeführt werden, entlasten sie die Rechenleistung des Servers. JDBC stellt die entsprechende Schnittstelle zur Verfügung, um mit Java-Applets auf die Datenbank zuzugreifen. [Sunc] Ein Java-Applet kann in einem eigenen Fenster dargestellt werden, welches u.a. graphikfähig ist. Im Gegensatz zu Java-Servlets, muss hier nicht zwingend HTML-Code generiert werden, der vom Browser des Client-Rechners dargestellt wird, weil man die Möglichkeit hat, in dem Fenster des Applets Ausgaben zu generieren, die unabhängig von HTML sind. Sollte also z.b. eine Daten-anfrage über ein Servlet gestellt werden, so besteht die Möglichkeit, die Ergebnisse direkt in diesem Fenster auszugeben. Der größte Nachteil von Applets ist, dass auf der Seite des Client eine JVM vorhanden sein muss, die an den Browser angeschlossen ist, damit ein Applet, welches über das Internet übertragen wird, auch ausgeführt werden kann. Allerdings ist mittlerweile bei den Browsern Netscape und Internet-Explorer eine JVM im Funktionsumfang enthalten. Diese beiden Browser die weiteste Verbreitung. Darüber hinaus wird die Rechenleistung des Client beansprucht, ob der Benutzer das nun möchte oder nicht. Ist der Rechner des Benutzers zu langsam, so ist das Arbeiten mit den Applets unbefriedigend. Dazu kommt noch, dass ein Applet über das Netz übertragen werden muss. Zusammengefaßt heißt das, Applets bieten zwar in bestimmten Bereichen Vorteile gegenüber CGI, aber es müssen viele Bedingungen vorhanden sein, damit Applets nicht zu einer Belastung des Benutzers werden. Was benötigt wird, ist eine Lösung auf der Server-Seite, die auf Java basiert, nicht zu viel Rechenzeit beansprucht und nur die notwendigsten Daten über das Netz transportiert. Java-Servlets bieten in dieser Hinsicht einige Möglichkeiten.

108 7.5.2 Java-Servlets Web-Server Servlet Datenbank Java-Servlets sind Java-Programme, die die Klasse HttpServlet erweitern und am Web- Server auf einer JVM ausgeführt werden. Sie können für jeden beliebigen Zweck eingesetzt werden, man kann also prinzipiell aus jedem Java-Programm ein Servlet erstellen, wobei darauf zu achten ist, dass Graphik-Ausgaben speziell zu behandeln sind, wobei hier nicht weiter darauf eingegangen wird. Servlets liegen in einem Verzeichnis, welches der Web- Server kennt, und werden beim Start des Web-Servers initialisiert. Damit Servlets vom Benutzer benutzt werden können, werden sie in HTML-Seiten in eine Formular-Umgebung eingebaut, beispielsweise um ein Servlet über einen Knopf (Button) zu starten. Die Klasse HttpServlet bietet u.a. die Möglichkeiten, Formular-Felder auszulesen oder mit Text zu füllen. Mit dieser Funktionalität ist es möglich, die Anfragen des Benutzers an eine Datenbank an das Servlet zu übermitteln. Servlets haben über JDBC die Möglichkeit auf Datenbanken zuzugreifen und sind multi-threaded, d.h. im Gegensatz zu CGI wird nur ein Servlet für jeden Dienst benötigt und dieses Servlet kann von mehreren Benutzern gleichzeitig benutzt werden. [Sunb] Damit der Benutzer an die Daten aus der Datenbank kommen kann, gibt er seine Anfrage am Browser ein und das Servlet greift die Daten ab und berechnet die Anfrage an die JDBC-Schnittstelle. Die JDBC-Schnittstelle kommuniziert über die JDBC-ODBC-Driver- Bridge mit der ODBC-Schnittstelle der Datenbank und erhält auf dem gleichen Weg die Antwort der Datenbank. Die Antwort wird dann, codiert in HTML, vom Servlet an den Browser des Benutzer geschickt und dargestellt. Das bedeutet, der Browser des Benutzer braucht keine JVM zu unterstützen, wie es bei Java-Applets notwendig ist. Damit Servlets eingesetzt werden können, muss der Web-Server Servlets unterstützen, also eine JVM zur Ausführung der Servlets zur Verfügung haben und diese auch ansteuern können. Da Java-Servlets eine neue Technologie sind, existieren noch nicht so viele Standardlösungen für die gängigen Probleme, wie es bei CGI der Fall ist. Andererseits hat sich Java schon weit verbreitet, da diese Sprache unabhängig von der Betriebssystem- Plattform ist und sich deswegen schon viele Programmierer damit beschäftigt haben. Für die meisten Datenbanken gibt es mittlerweile JDBC-Schnittstellen, weswegen Java in Bezug auf Internet und Datenbanken immer relevanter wird.

109 7.6 Proprietäre Datenbank-Schnittstellen im Gegensatz zur eigenen Anbindung Bisher wurden die einzelnen Software-Komponenten vorgestellt und erläutert, wie man diese untereinander und miteinander verbindet. Neben dem Browser, dem Web-Server und der Datenbank standen die Schnittstellen zwischen diesen Programmen im Vordergrund, weswegen auf CGI und ASP auf der einen Seite und Java-Applets und -Servlets mit der Unterstützung von ODBC-JDBC auf der anderen Seite eingegangen worden ist. Es ist zu beachten, dass diese Schnittstellen frei zu-gängig und dokumentiert sind, d.h. man ist in der Lage, sie zu benutzen und sie den anderen Software-Komponenten anzupassen. Es wurde allerdings noch gar nicht auf die zeitlichen und materiellen Kosten bei der Erstellung und Wartung dieser Art der Anbindung eingegangen. Die Alternative zur selbst erstellten Datenbank-Anbindung nennen wir proprietäre Datenbank-Anbindung. In Kapitel 3.3 wurde schon auf die Vorteile der standardisierten Datenbank-Anbindung eingegangen, die z.b. die Möglichkeit des leichten Austausches der Datenbank beinhalten. Hier soll noch einmal auf die Nutzung der proprietären Schnittstellen eingegangen werden und dies speziell im Zusammenspiel mit dem Web-Server Was ist eine proprietäre Datenbank-Anbindung? Datenbank Web-Server Unter einer proprietären Datenbank-Anbindung verstehen wir eine Software-Anbindung, die nicht selber erstellt, sondern gekauft wird. Diese Software soll einen Web-Server und die angebundene Datenbank enthalten. Diese Anbindung kann von der entsprechenden Firma, wo gekauft wird, besser optimiert werden, als wenn man sie selber schreibt, weil diese Firma mehr Informationen über Datenbank und Web-Server hat als der Anwender, was daran liegt, dass beide Komponenten entweder von der Firma erstellt wurden oder im Besitz dieser Firma sind, die Firma also mehr Informationen über die Schnittstellen und Funktionen als der Anwender hat. Der Vorteil für den Anwender ist also die Geschwindigkeit und das Entfallen der Notwendigkeit, die Anbindung selber realisieren zu müssen. Eine proprietäre Datenbank-Anbindung sollte sich in der Benutzung genauso verhalten, wie jede andere kommerzielle Software. Die Installation sollte einfach durchführbar sein, ohne dass der Benutzer viel über die Hintergründe der Software wissen muss. Sobald die Software installiert ist, soll die Benutzung einfach gehalten sein. Es muss also möglich sein, anhand einer Anleitung die Benutzung der Software zu verstehen und nach dem Lesen

110 der Anleitung mit der Software umgehen zu können. Bei der Administration der Software dürfen keine Kenntnisse über die Quelltexte oder die Struktur der Software vorausgesetzt werden. Im nächsten Abschnitt werden einige Software-Produkte davon vorgestellt Beispiele für proprietäre Datenbank-Anbindungen Um einen Überblick zu bekommen, welche Software die angestrebten Ziele erfüllt, wurde eine Netz-Recherche durchgeführt, wobei die Werbe-Seiten der entsprechenden unternehmen als Quelle benutzt wurden. Die Programme, die hier genannt werden, sind nicht getestet worden und es wird keine Garantie dafür übernommen, ob sie das leisten, was im Internet versprochen wird. Das liegt daran, dass der zeitliche Rahmen des Seminars eine weitere Recherche nicht erlaubt und die meisten Programme dafür auch gekauft und installiert werden müssten. ffl Apache mit My-SQL Anbindung: Beide Produkte sind kostenlos erhältlich, da sie unter die GPL (GNU Public Licence) fallen. Die Anbindung der Datenbank-Software My-SQL ist in den neueren Versionen des Web-Servers Apache mit eingebaut. über Werkzeuge, die die Administration der Datenbank oder des Web-Servers erlauben, ist nichts bekannt. ffl Oracle Internet Application Development Tools: Die Firma Oracle wirbt mit den Programmen WEB DB, dem Developer Server und der JDeveloper Suite eine kompakte Datenbank-Lösung, die Internet-basiert ist, liefern zu können. ffl mysap: Die Firma SAP wirbt mit dem Paket mysap, welches an die Gegebenheiten einer Firma angepasst werden kann und welches XML basiert sein soll. ffl Microsoft Internet Information Server mit Microsoft BackOffice: Microsoft sehen ihrem Paket bestehend aus Web-Server und Datenbank-Office eine kompakte Lösung, die in der Lage ist, die gängigen Probleme einer Firma bzgl. Datenbank-Anbindungen zu bewältigen Ist eine proprietäre Datenbank-Anbindung besser als eine Selbst-erstellte? Die Frage ist, ob es sich wirklich rechnet, eine solche Software zu kaufen, anstelle die Anbindung selber vorzunehmen, was auch die Möglichkeit mit einschließt, kostenlose Datenbank- und Web-Server-Produkte zu nutzen.

111 Vorteile einer proprietären Datenbank-Anbindung Natürlich muss die Anbindung zwischen Web-Server und Datenbank nicht mehr selber vorgenommen werden, d.h. die Zeit für Planung und Codierung entfällt. Dazu kommt, dass eine Firma, die sich gezielt mit dieser Anbindung auseinander-setzt, wahrscheinlich zu einem besseren Ergebnis kommt, was die Effizienz angeht. Das könnte sich zum Beispiel in der Zugriffs- und Antwortzeit der Datenbank äußern. Da eine solche Firma in den meisten fällen Web-Server und Datenbank selber produziert hat, kennt sie die Feinheiten ihrer Software und hat möglicherweise nähere Kenntnisse darüber, wie man die Leistung dieser Anbindung optimieren kann. Für den Kunden ist es wichtig, dass er sich um Probleme mit der Software nicht selber kümmern muss. Er erwartet als Käufer Service in Form von Software-Updates oder Technikern, die bei Problemen zur Verfügung stehen. Da der Software-Markt sich schnell weiterentwickelt ist es oft notwendig, die Software an neue Gegebenheiten und Standards anzupassen. Darum muss sich der Kunde nicht kümmern. Er kann davon ausgehen, dass die Firma, die die Software geschrieben hat, die Software immer auf dem neuesten Stand halten wird, um konkurrenzfähig zu bleiben Nachteile einer proprietären Datenbank-Anbindung Jedoch stellen die Vorteile einer proprietären Datenbank-Anbindung auch gleichzeitig die Nachteile dar. Der Kunde muss für die Software zahlen. Oft bieten die Firmen überhaupt nicht die Möglichkeit, dass ein Angestellter der Firma die Software installiert, da für diesen Zweck Programme geschrieben wurden, mit denen sich der Kunde auseinander-setzen muss. Sollte es aufgrund technischer Vorgaben Probleme in der Anbindung geben, ist der Kunde auf Software-Updates angewiesen, wobei er noch nicht einmal mit Sicherheit weiß, dass diese Probleme gelöst werden. Natürlich muss sich der Benutzer von Software, die selbst angebunden wird, auch mit solchen Problemen beschäftigen, aber in dem Fall, z.b. bei JDBC, ist die Schnittstelle frei verfügbar, man kann sich also die Dokumentation bzw. Rat und Hilfe im Internet suchen. Bei einer proprietären Anbindung hat man diese Hilfe nicht zur Verfügung. Es besteht also eine Abhängigkeit des Kunden von der Firma, wo er seine Datenbank- Anbindung gekauft hat und er kann im Normalfall keine der enthaltenen Komponenten gegen eine andere austauschen, da sich dann die Schnittstellen ändern werden und ihm die Firma, wo er zuerst gekauft hat, bei dieser Anpassung nicht behilflich sein wird, weil es sich dann ja um Konkurrenzprodukte handelt. Das heißt, er kann höchstens auf ein komplett neues Paket umsteigen, was wieder Kosten mit sich bringt und keine Sicherheit bietet, unbedenklicher im Einsatz zu sein. Es muss also genau überprüft werden, was man von einer proprietären Datenbank-Anbindung erwartet und ob die dafür ausgewählte Software das bietet, was man sich erhofft.

112 7.7 Fazit An dieser Stelle soll zusammengefaßt werden, welche Software für welchen Zweck eingesetzt werden kann. ffl Server-seitige Technologien, wie z.b. Servlets, ASP oder CGI sind einsetzbar, wenn es um einfache Anfragen an die Datenbank geht und die Visualisierung der Daten nicht zu aufwendig ist. ffl Im Gegensatz zu Servlets bieten Applets die Möglichkeit einer komplexeren Visualisierung, wobei Rücksicht darauf genommen werden muss, dass das Applet und die Daten über das Netz transportiert werden müssen, der Browser des Benutzer eine JVM benötigt und der Rechner des Benutzer die notwendige Rechenkapazität bieten muss, das Applet auszuführen. ffl Nutzt man CGI, so hat man eine ausgereifte Technologie, die jedoch für viele Probleme nicht mehr zeitgemäß ist und keine graphische Visualisierung bietet. ffl Ob eine proprietäre Datenbank-Anbindung sinnvoll ist, muss im Detail abgewägt werden und man muss sich über die Abhängigkeit zu der Firma, wo man die Anbindung kauft, im klaren sein.

113 Teil II Einführung in Digitale Bibliotheken 99

114

115 Kapitel 8 Traditionelles und digitales Publikations- und Bibliothekswesen Daniel Pawlowski Vor 5000 Jahren entwickelten sich die ersten Schriften. Und mit ihnen wenig später die ersten Bibliotheken. Die Bibliotheken blieben aber nicht immer in der gleichen Form bestehen, sondern passten sich in einer evolutionären Entwicklung stets der kulturellen Umgebung an. So entwickelte sich im Laufe der Jahrhunderte die Bibliothek, wie wir sie heute kennen. Doch auch sie wird sich weiterentwickeln müssen, da sie in unserer Zeit immer mehr an ihre Grenzen stößt. Erste Ansätze dazu wurden bereits in Form von digitalen Bibliotheken gemacht. Aufgabe dieser Seminar-Arbeit ist es zu zeigen, welche Änderungen die digitalen Bibliotheken im Publikationsprozeß und Bibliothekswesen mit sich bringen werden. 101

116 102 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN 8.1 Einleitung Die Bibliothek hat sich im Laufe der Geschichte in einer evolutionären Entwicklung ständig seiner Umwelt angepasst. Mit sich ändernden Anforderungen änderte sich auch das Erscheinungsbild Wie das flüchtige Wort festgehalten wurde Die Grundlage für eine Bibliothek ist die Schrift. Warum aber das flüchtige Wort und das Erinnerungsvermögen dem Menschen eines Tages nicht mehr genügten, ist bis heute leider unbekannt, nicht aber die Zeit, zu der dieses geschah. Rund 3000 Jahre vor Chr. begannen die Einwohner von Mesopotamien und Ägypten das Wort zu speichern. Der dafür verwendete Informationsträger war zu diesem Zweck in Mesopotamien die Tontafel. Auf ihr ritzte man in den noch feuchten Ton die Schriftzeichen mit einem Griffel und ließ den Ton anschließend trocknen oder brannte ihn. Die Schreibschüler mussten dabei hunderte von Zeichen beherrschen. Im Laufe der Zeit änderten sich die Schriftarten, die Anzahl der Zeichen und auch das Speichermedium. Die ersten Alphabete sind im Vergleich zum Alter der Schrift noch sehr jung. Sie treten erst ab dem 15./16. Jahrhundert vor Chr. auf. Das griechische Alphabet als Vorgänger unserer lateinischen Schrift sogar erst im 8. Jahrhundert vor Christus. Die Schrift hat sich in dieser Zeit ständig weiterentwickelt. Von der Ideenschrift über die Wort-Lautschrift bis hin zur heutigen Buchstabenschrift Der Wandel der Bibliotheken in der Zeit Die ersten Bibliotheken sind so alt wie die Schrift. Sie waren aber eher eine Ansammlung und Lagerung von Dokumenten jeglicher Art (häufig wirtschaftlicher Natur) und bei weitem nicht vergleichbar mit dem, was wir heute unter einer Bibliothek verstehen. Aber so wie sich die Schrift von der Ideenschrift zur Wort-Lautschrift und ihre Träger von den Tontafeln über Papyrus, Pergament bis zum heute benutzten Papier und anderen Medien mit den Jahren veränderte, so veränderte sich auch die Gestalt der Bibliothek. Von den ersten Bibliotheken in Mesopotamien und Ägypten ging es über die Bibliotheken der römischen und griechischen Zivilisation mit der berühmten Bibliothek von Alexandria (Museion), den Klosterbibliotheken im Mittelalter und den privaten Fürstenbibliotheken im 17. und 18. Jahrhundert zu der heutigen öffentlichen Literaturversorgung durch die uns bekannte Bibliothek. Während die frühen Bibliotheken oftmals nur eine Ansammlung von Dokumenten jeglicher Art waren, wurde erst durch Gutenberg im Jahr 1450 eine nähere Spezifizierung möglich. Der Buchdruck ermöglichte eine Aufspaltung der Bibliothek in Archive mit ihren Unikaten und Bibliotheken mit ihren Druckwerken.

117 8.1. EINLEITUNG Wird sich die Bibliothek weiterentwickeln? Wenn man sich die Entwicklung der Schrift und der Bibliotheken anschaut, wird man im Laufe der Jahrhunderte keinen Stillstand entdecken können. Dass die heutige Bibliothek in ihrer Form den Anforderungen einer - im Vergleich zu den letzten Jahrhunderten - hochtechnisierten Welt genügt, darf bezweifelt werden. Nach Schätzungen verdoppelt sich die Anzahl der Bücher alle 15 Jahre, die der im wissenschaftlichen Bereich sogar alle 10 Jahre. Keine Bibliothek der Welt kann diese Informationsflut noch aufnehmen, geschweige denn verarbeiten. Man muss sich also nach Alternativen des traditionellen Bibliotheksund Publikationswesen umschauen. Ein vielversprechender Ansatz hierfür sind die digitalen Bibliotheken. Um sie verstehen zu können, wird im folgenden der traditionelle Weg eines Buches in eine Bibliothek und die Aufgabe einer Bibliothek mit den Nachteilen gezeigt. Anschließend soll deutlich gemacht werden, inwieweit die digitale Form das traditionelle Publikations- und Bibliothekswesen verändert, was für Vorteile man sich davon verspricht und welche Zukunftsaussichten bestehen.

118 104 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN 8.2 Der traditionelle Publikationsprozeß Bereits ca Jahr vor der Erfindung der Buchdrucks fanden die erste nachweislichen Buchproduktionen und damit die ersten Ansätze verlegerischer Tätigkeiten im alten Ägypten statt. Ägyptische Totengräber schrieben die den Verstorbenen ins Grab mitgegebenen Totenbücher auf Vorrat ab und verkauften sie an Hinterbliebene [Bar96]. Während früher die Form der Publikationsprozeß noch eine sehr einfache Struktur aufwies, ist sie heute komplexer. Nach [BH + ] können insgesamt 3 Klassen identifiziert werden, die an einem Publikationsprozeß im traditionellen Sinne beteiligt sind. Dabei können die Akteure nicht immer unbedingt nur einer festen Klasse zugeordnet werden können Der Produzenten-Workflow Produzenten sind die Parteien, die an der Produktion von Literatur beteiligt sind. Man kann dabei die Akteure Autoren, Verlage und Lektoren identifizieren. Autor Verlag Idee Manuskript Vertrag Schickt Version Korrekturwünsche & Verbesserungsvorschläge Interesse Prüfung d. Lektor Honorar, Freiexemplare etc. Anmeldung VG Wort Buchproduktion, Werbung etc. Fertige Version Abbildung 8.1: Der Produzenten-Workflow Wenn ein Autor eine Idee zu einem Buch hat, fertigt er ein Manuskript an, welches er an einen oder mehrere Verlage sendet. Hat einer der Verlage Interesse an dem Buch, wird ein Vertrag zwischen Autor und Verlag geschlossen. Der Autor erstellt eine erste Version des Buches und schickt es an den Verlag, wo ein Lektor die Version überprüft und Korrekturwünsche oder Verbesserungsvorschläge an den Autor gibt. Wenn der Lektor irgendwann mit einer Version des Buches zufrieden ist, hat das Buch die Produktionsreife erlangt. Der Verlag setzt einen Preis für das Buch fest, beginnt Werbung dafür zu machen und liefert Bücher an Buchhandlungen, Bibliotheken etc. aus. Der Autor erhält jetzt vom

119 8.2. DER TRADITIONELLE PUBLIKATIONSPROZESS 105 Verlag Freiexemplare, Rabatte bei Bestellung seines eigenen Buches und zu bestimmten Zeitpunkten Honorare. Weiterhin wir das Buch bei der VG Wort 1 angemeldet. Wenn eine Auflage des Buches vergriffen ist, wird der Autor vom Verlag beauftragt, eine neue Version mit Korrekturen/Verbesserungen für eine Neuauflage zu erstellen. Der Autor erstellt eine neue Version, die vom Lektor geprüft wird und die oben skizzierte Prozedur wiederholt sich Der Distributoren-Workflow Distributoren sind die Parteien, die die von den Produzenten erstellte Literatur den Konsumenten zur Verfügung stellen. Als Akteure gibt es auf der Distributorenseite die Bibliotheken und den Buchhandel. Der Buchhandel bekommt Bücher vom Verlag zugeschickt oder erwirbt sie auf Kommission, d.h. nicht verkaufte Bücher können nach einer bestimmten Zeitspanne an den Verlag zurückgeschickt werden. Die Buchhandlung verkauft die Bücher dann weiter an die Konsumenten. Im Hinblick auf digitale Bibliotheken jedoch wesentlich interessanter sind die Bibliotheken als Distributoren. Die Aufgaben einer Bibliothek umfassen die Beschaffung, Erfassung, Erschließung, Recherche und das Vermitteln von Informationen, auf die im nächsten Kapitel näher eingegangen wird. Nach der Beschaffung, Erfassung und Erschließung kann das Buch einem Konsumenten zur Verfügung gestellt werden. Verlag Gibt Bücher zurück Erhält Bücher Erhält Bücher Verkaufen Buchhandlung Bibliothek Beschaffen, Erfassen, Indexieren, Recherchieren, Vermitteln v. Inf. Abbildung 8.2: Der Distributoren-Workflow 1 Die VG Wort ist eine Organisation, die Tantiemen aus Zweitnutzungsrechten (d.h. bei Vervielfältigung und Zweitnutzung) einnimmt und an Verlage und Autoren jährlich weiter gibt. Daher ist die VG Wort auch für digitale Bibliotheken wichtig, da sie von Bibliotheken und anderen Institutionen von Vervielfältigungen bzw. Zweitnutzung eines Buches erfährt. [Wor99]

120 106 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN Der Konsumenten-Workflow Die Literatur wird von den Konsumenten genutzt. Hier werden nur der Einzelleser (keine Lese-Zirkel etc.) und seine Beziehung zu den oben genannten Distributoren und Produzenten betrachtet. Der Konsument sucht bei seiner Recherche gezielt oder ungezielt nach einem Buch. Dieses Buch kauft er sich in einer Buchhandlung oder leiht es sich in einer Bibliothek aus. Der Leser nutzt dieses Buch auf unterschiedliche Arten und schickt evtl. Anmerkungen zu einem Buch an den Verlag, den Autor oder andere Lesern (Rezension). Nach der Nutzung wird ein Buch entweder aufbewahrt oder weitergegeben. Einzelleser Kauft Buch Buchhandlung Schickt Anmerkung Leiht Buch Autor Verlag Bibliothek Abbildung 8.3: Der Konsumenten-Workflow

121 8.3. DIE AUFGABEN EINER BIBLIOTHEK Die Aufgaben einer Bibliothek Die Aufgaben einer Bibliothek lassen sich in die folgenden vier Teilbereiche gliedern: ffl Beschaffen und Erfassen ffl Indexieren ffl Recherche ffl Vermitteln von Informationen Beschaffen und Erfassen Es müssen die Dokumentationseinheiten beschafft werden, die für das Zielpublikum von Nutzen sind. Dazu erwirbt die Bibliothek die gewünschte Einheit oder bekommt sie vom Verlag geschenkt. Wenn dabei für den Benutzer benötigte Dokumente übersehen werden, kommt es zu einer unvollständigen Dokumentation. Es muss auch bei neuen Dokumentationseinheiten geprüft werden, ob diese bereits früher schon einmal eingespeichert worden sind. Es folgt die formale Erfassung. Hierbei werden einige äußere Dinge wie etwa Verfasser, Sachtitel, Herstellungsjahr etc. erfasst. Da das Sammeln und Ausleihen die Hauptaufgabe der Bibliothek ist, liegt der Schwerpunkt beim formalen Erfassen der meist sehr großen Bestände. Der alphabetische Hauptkatalog kann dann Auskunft darüber geben, ob ein dem Verfasser oder Sachtitel nach bekanntes Buch vorhanden ist und wo es steht Indexieren Indexieren ist das inhaltliche Erschließen der Dokumentationseinheit. Es werden der Dokumentationseinheit Deskriptoren (im einfachsten Fall Schlagwörter) zugeordnet. Die inhaltliche Erschließung stellt also fest, wovon ein Dokument handelt. Die inhaltliche Erschließung ist zusätzlich zur formalen Erfassung notwendig, damit vom Inhalt her auf die Dokumentation geschlossen werden kann. Dies erfolgt bei den großen Beständen und durch den Aufwand in einer Bibliothek durch den systematischen Katalog und/oder den Schlagwortkatalog weniger detailliert als die formale Erschließung. Nach [Gau95] sind die wichtigsten und gängigsten Möglichkeiten des inhaltlichen Erschließens: ffl Sachtitel: Durch den Sachtitel und das Inhaltsverzeichnis wird auf den Inhalt geschlossen. ffl Annotation: Der Sachtitel wird durch die Dokumentationsstelle durch Bemerkungen, Erläuterungen etc. ergänzt.

122 108 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN ffl Referat: Als Referat wird ein Bericht oder Vortrag über ein Dokument bezeichnet. ffl Zusammenfassung: Das Dokument wird in Kurzform und auf das wesentliche bezogen wiedergegeben. ffl Freies Indexieren: Durch mehrere unverbundene nebeneinander gestellte Wörter wird der Inhalt möglichst treffend gekennzeichnet. ffl Gebundenes Indexieren: Es dürfen im Gegensatz zur freien Indexierung nur Wörter verwendet werden, die durch ein festes Ordnungssystem ausdrücklich zugelassen sind Recherchieren Die Recherche ist das gezielte Suchen und Wiederfinden von Dokumentationseinheiten zu einem interessierenden Sachverhalt. Für die Recherche muss dieser interessierende Sachverhalt durch Deskriptoren ausgedrückt werden und bildet dann die formale Suchfrage. Mit der formalen Suchfrage wird der Deskriptorenspeicher gezielt nach relevanten Dokumenten abgefragt. Das Ergebnis der Abfrage des Deskriptorenspeichers sind z.b. die Nummern der Dokumente, die für die Suchfrage relevant sind. Mit diesen Dokumentennummern kann dann auf die Dokumente selbst im Dokumentenspeicher zugegriffen werden Vermitteln von Informationen Vermitteln heißt in diesem Sinne nicht nur das Bereitstellen eines Exemplars einer Veröffentlichung, sondern kann pädagogisch verstanden werden. Es wird durch die Vermittlungsarbeit der Bibliothek den Besuchern die Informationsfindung erleichtert. In dieser Aufgabe geht es also auch um die Schulung der Benutzer. Diese Aufgabe wird natürlich in einer öffentlichen Bibliothek mit Blick auf ein anderes Publikum anders zu erfüllen sein als in einer wissenschaftlichen Bibliothek.

123 8.4. NACHTEILE DES TRADITIONELLEN BIBLIOTHEKSWESENS Nachteile des traditionellen Bibliotheks- und Publikationswesens Wie bereits in der Einleitung gezeigt wurde, haben sich die Bibliotheken in ihrer Form im Lauf der Geschichte ständig an ihre Umwelt angepasst. Heute können viele Nachteile traditioneller Bibliotheken erkannt werden, die eine weitere Veränderung erzwingen Nachteile traditioneller Bibliotheken Traditionelle Bibliotheken weisen folgende Probleme auf: ffl Die Menge der neuen Dokumente kann kaum noch beherrscht werden. So hatte zum Beispiel die Library of Congress in Washington 1992 bereits 100 Millionen Gegenstände, darunter 15 Millionen Bücher (5600 vor dem Jahr 1500 hergestellt) und 39 Millionen Manuskripte [L.O99]. Dies ist jedoch nur ein kleiner Teil der weltweit vorhandenen Dokumente, und aktuelle Schätzungen gehen davon aus, dass sich der schriftliche Output alle 15 Jahre (der wissenschaftliche sogar alle 10 Jahre) verdoppelt [Hil]. Keine Bibliothek der Welt ist in der Lage, dieser Menge Herr zu werden. ffl Es besteht eine Ortsabhängigkeit, die Dokumente müssen vor Ort aufzubewahrt werden. Bei wertvollen Einzelexemplaren ist dies besonders hinderlich. ffl Es entstehen hohe Kosten durch Anschaffung, Gebäude, Pflege des Bestands etc. ffl Neue Dokumentarten wie Hypertexte, Interaktive Dokumente oder Animationen können nur umständlich (zum Beispiel auf einer CD-ROM) zur Verfügung gestellt werden. ffl Die Erfassung und Indexierung erfolgt von Hand. Dadurch können nur begrenzte Informationen über ein Dokument aufgenommen werden. ffl Der letzte Punkt führt zu einer schwachen Recherchefunktion. Durch eventuell nicht vorhandene Stichwörter werden evtl. nicht alle relevanten Dokumente zu einem Sachverhalt gefunden Nachteile traditionelles Publikationswesen Beim traditionellen Publikationswesen ist vor allem die lange Dauer des Publikationsprozesses zu nennen. Da wissenschaftliche Texte schnell veralten, Publikationsprozesse von 2-3 Jahren aber keine Seltenheit sind, werden Dokumenten häufig erst dann veröffentlicht, wenn sie bereits uninteressant geworden sind.

124 110 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN 8.5 Digitale Bibliotheken In diesem Abschnitt werden digitale Bibliotheken und ihre Einwirkungen auf den traditionellen Publikationsprozeß kurz vorgestellt. Dabei werden aber bei der Vorstellung digitaler Bibliotheken nicht die verschiedenen Architekuransätze betrachtet, sondern vielmehr die Auswirkungen auf das traditionelle Bibliotheks- und Publikationswesen untersucht Was sind Digitale Bibliotheken Die Hauptbestandteile digitaler Bibliotheken sind organisierte Sammlungen digitaler Informationen, die über das Internet angesprochen werden können. Im Gegensatz zu traditionellen Bibliotheken kann eine digitale Bibliothek nicht nur materielle Dokumente sondern auch immaterielle Dokumente beinhalten. Die Aufgaben der digitalen Bibliothek ändern sich nicht. Es können aber eine größere Anzahl an Dokumenten aufgenommen werden, da die digitale Speicherung weniger räumlichen Platz verbraucht. Auch kann nur der Link zu einem Dokument gespeichert werden, so dass nicht jede Bibliothek alle Dokumente vor Ort haben muss, sondern nur einige wenige Exemplare Änderungen im Publikationsprozeß und den Bibliotheksaufgaben Änderungen im Publikationsprozeß Im Publikationsprozeß kommt ein neuer Akteur dazu, der Administratoren [Bol]. Er ist für die Hard- und Software im Digitalen Publikationsprozeß zuständig. Die Grenzen zwischen den verschiedenen Akteuren verschwimmen jedochstark,sodass zum Beispiel ein Verlag neben Produzent, Administrator und Anbieter einer eigenen evtl. kommerziellen digitalen Bibliothek zugleich auch Distributor ist. Das kann zu inhaltlichen und auch zu rechtlichen Problemen führen. Der Inhalt kann ohne Qualitätssicherung als wissenschaftliche Publikation angeboten werden. Auch kann es Probleme mit durch Urheberrecht und Copyright 2 geschützten Dokumenten geben, etwa was die Zweitverwertung angeht. Im Publikationsprozeß besteht die Möglichkeit von Vorveröffentlichungen von Teilen der Publikation in digitaler Form. Dies hat vor allem im wissenschaftlichen Bereich Vorteile. So kann zum Beispiel ein Buch in digitaler Form früh auf den Markt kommen, wenn also das Interesse besonders groß ist. Später kann dann eine gedruckte Form als Nachschlagewerk folgen. Weiter besteht die Möglichkeit der teilweisen Automatisierung des Publikationsprozesses. Darauf soll aber an dieser Stelle nicht weiter eingegangen werden. 2 Obwohl UrheberrechtundCopyright in der Regel synonym gebrauchtwerden, gibt es einen wichtigen Unterschied im Geltungsbereich. Das deutsche Urheberrecht schützt Dokumente in Deutschland und in allen dem Urheberrecht beigetretenen Ländern und umgekehrt. Das Copyright schützt Werke aus aller Welt, jedoch nur in den USA und nur wenn sie mit dem Copyrightvermerk geschützt sind, also mit einem eingekreisten C und der Jahreszahl.

125 8.5. DIGITALE BIBLIOTHEKEN Änderungen in den Aufgaben Der Schwerpunkt wird bei den Aufgaben nicht mehr wie vorher bei der formalen Erfassung der Dokumente liegen, sondern eher bei der inhaltlichen Erschließung. Während sich die vollständige inhaltliche Erschließung eines Dokumentes in der traditionellen Bibliothek als nahezu unmöglich gestaltete, wird bei Dokumenten in digitaler Form sogar eine problemlose Volltextsuche möglich. Die Erfassung wird bei digitalen Dokumenten aber auch erschwert. So müssen bei digitalen Bibliotheken zusätzliche Dokumentarten inhaltlich erfasst werden, wie zum Beispiel Animationen, Musikstücke und so weiter. Ein weiteres Problem bei der Erschließung ist, dass die Dokumente dynamisch und unbeständig sind. So kann es bei einer Verlinkung dazu kommen, dass ein Dokument durch Verschiebung oder Löschung nicht mehr vorhanden sind, der Link dies jedoch nicht anzeigt.

126 112 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN 8.6 Vorteile von Digitalen Bibliotheken Digitale Bibliotheken haben gegenüber traditionellen Bibliotheken viele Vorteile. Einige davon sollen im folgenden kurz vorgestellt werden Vorteile im Bibliothekswesen Als Vorteile im Bibliothekswesen können genannt werden: ffl Es besteht die Möglichkeit der automatisierten Erfassung und Indexierung. Hierdurch kann der Deskriptorenspeicher umfangreicher werden und die Suche nach Sachverhalten bis hin zur Volltextsuche verbessern. ffl Innerhalb von umfangreichen Texten kann sehr schnell nach Begriffen gesucht werden. ffl Kostbare Originale werden geschont. ffl Textteile können extrahiert und weiterverarbeitet werden. ffl Durch Ortsunabhängigkeit ist der Zugriff auf ein Dokument möglichohne Rücksicht auf den Aufenthaltsort der Lesers und des Dokumentes. ffl Ein Dokument kann nicht ausgeliehen und damit für andere Benutzer blockiert sein. ffl Es findet eine erhebliche Kostenreduktion statt. ffl Es können mehr Dokumentarten angeboten werden. ffl Es ist möglich, zwischen verschiedenen Dokumenten per Hypertext zu springen Vorteile im Publikationsprozeß Vorteile im Publikationsprozeß sind: ffl Auf dem PC erstellte Artikel müssen nicht erst gedruckt und als Bücher oder Zeitschriften auf dem langsamen Postweg versandt werden. ffl Die Kommunikation und Zusammenarbeit mit dem Lektor wird durch verbessert. ffl Durch Groupware-Editoren wird die Zusammenarbeit mehrerer Autoren an einem Dokument verbessert.

127 8.7. ABSCHLIESSENDE ANMERKUNGEN Abschließende Anmerkungen Das Publikations- und Bibliothekswesen in der traditionellen Form ist, wie bereits in der Einleitung vermutet, an seine Grenzen gestoßen. Ob jedoch das traditionelle durch das digitale Publikations- und Bibliothekswesen vollständig ersetzt werden kann, bleibt wie die folgende Zukunftsprognose zeigt, unwahrscheinlich. Es kann davon ausgegangen werden, dass das digitale Bibliotheks- und Publikationswesen das traditionelle in naher Zukunft nicht vollständig ersetzen können wird. Der technologische Stand und die finanziellen Mittel reichen nicht aus, um den bestehenden Stand an Dokumenten zu digitalisieren. Selbst wenn keine neuen Dokumente angeschafft würden, wäre man über Jahre mit der Digitalisierung beschäftigt. Und dann müssten die Dokumente angeschafft werden, die in der Zwischenzeit dem Benutzer vorenthalten wurden und diese evtl. noch digitalisieren. Während dieser Zeit könnten aber keine neuen Dokumente angeschafft werden, wegen der hohen Kosten etc.. Auch kann davon ausgegangen werden, dass die Akzeptanz bei vielen Benutzern fehlen würde eine rein digitale Bibliothek zu benutzen. Viele möchten zum Beispiel die Bücher ausleihen und zu Hause oder unterwegs lesen, was aber nur schwer realisierbar ist. Eine weitere Gefahr besteht im Informationsverlust. Werden die digitalen Bibliotheken kommerziell geführt, gibt es keine Garantie dafür, dass komplette Fachgebiete, die unrentabel sind, einfach gelöscht werden. Obwohl das digitale Wort das geschriebene in naher Zukunft nie ersetzen können wird, besitzt das digitale Bibliotheks- und Publikationswesen ein enormes Potential, zum Beispiel um der Flut neuer Bücher Herr zu werden. Es wird wohl in naher Zukunft das traditionelle Bibliotheks- und Publikationswesen nicht ersetzt, sondern gerade im wissenschaftlichen Bereich sinnvoll durch das digitale Bibliotheks- und Publikationswesen ergänzt. Die Bibliothek der Zukunft wird also eine Mischform aus beiden sein. Die traditionelle Bibliothek wird als Grundgerüst mit ihren Funktionen vor allem im Bereich der Vermittlung von Informationen bestehen bleiben und die digitale Bibliothek als Teilbereich wird die Nachteile heutiger Bibliotheken beseitigen.

128 114 KAPITEL 8. DAS PUBLIKATIONS- UND BIBLIOTHEKSWESEN

129 Kapitel 9 Digitale Bibliotheken im Vergleich Jens Eschke Dieser Bericht befasst sich mit digitalen Bibliotheken, und dem Vergleich einiger ausgewählter digitaler Bibliotheken, die einen näheren Bezug zum Fachgebiet Informatik haben. Die Einleitung beschreibt welche Vorteile sich sowohl für die Anbieter als auch für die Benutzer bieten, wenn sie digitale Bibliotheken, anstatt herkömmlicher Bibliotheken, benutzen. Danach folgt die Einteilung der digitalen Bibliotheken in Kategorien, das heißt digitale Bibliotheken die sich ähneln werden unter einer Kategorie zusammengefasst. Als letztes folgt in der Einleitung welche Kriterien sich für einen Vergleich von digitalen Bibliotheken eignen. Mit der Vorstellung der einzelnen digitalen Bibliotheken befasst sich der nächste Abschnitt. Zu den in diesem Bericht vorgestellten digitalen Bibliotheken gehören: ACM, IEEE-CS, LINK, NCSTRL, NZDL, MeDoc und UniCats. Einige der vorgestellten digitalen Bibliotheken beinhalten sehr unterschiedliche Ansätze zur Architektur von digitalen Bibliotheken. In den abschließenden Anmerkungen kann man noch einmal die wichtigsten Unterschiede der vorgestellten digitalen Bibliotheken nachlesen. Als letztes folgt, für die weitere Vertiefung in dieses Gebiet, die für diesen Bericht verwendete Literatur. 115

130 116 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH 9.1 Einleitung Allgemeines zu digitalen Bibliotheken Die vorrangige Aufgabe von digitalen Bibliotheken ist es, Konsumenten Informationen zur Verfügung zu stellen. Diese Informationen werden den digitalen Bibliotheken von den Produzenten zur Verfügung gestellt. Dabei sind die Konsumenten unter anderem Studenten, Wissenschaftler und Personen die sich über ein bestimmtes Themengebiet informieren wollen, und die Produzenten sind Autoren, Verleger, insgesamt also die Anbieter von Literatur. Wie man sieht haben die digitalen Bibliotheken dieses Prinzip von den herkömmlichen Bibliotheken übernommen. Es gibt drei Hauptaufgaben für Bibliotheken: Sammeln, Katalogisieren und Extrahieren von Literatur. Das Sammeln von Literatur ist für den Aufbau eines Dokumentbestandes sehr wichtig, denn damit wird eine Bibliothek erst auf dem neusten Stand gehalten. Damit die vorhandene Literatur sinnvoll durchsucht werden kann, muss man sie vorher katalogisieren, dazu sollten vorher Informationen aus der vorhanden Literatur extrahiert werden. Mit Hilfe dieser Informationen werden dann bibliographische Daten erstellt, damitverwalten die meisten Bibliotheken ihren Dokumentbestand. Zu den bibliographischen Daten gehören der Name des Autors, der Titel des Dokuments, das Erscheinungsdatum und das Fachgebiet in das das Dokument eingeordnet werden kann. Mit Hilfe dieser bibliographischen Daten kann eine sehr schnelle und effiziente Suche im Dokumentbestand durchgeführt werden, in dem diese Daten von einer Suchmaschine verwaltet werden, die jedem Benutzer zur Verfügung steht. Diese Operationen finden sich auch bei den digitalen Bibliotheken wieder, denn ohne diese Operationen kann eine Bibliothek nicht existieren. Einer der Vorteile von digitalen Bibliotheken ist, im Vergleich zu normalen Bibliotheken, den Publikationsprozess zu verkürzen. Beispielsweise musste man früher auf die Veröffentlichungen von CSTR - Computer Science Technical Reports - warten, bis sie in einer Zeitschrift veröffentlicht wurden, die man dann gekauft hat oder in einer Bibliothek gelesen hat. Oder eventuell bekam man die Artikel irgendwann einmal per zugeschickt, sofern man sich in diverse Mailinglisten eingetragen hatte. Des weiteren war das Beschaffen von Grauer Literatur - grey Literature, das heißt Literatur (zum Beispiel: Vorlesungsmitschriften von Professoren) die in den meisten Fällen nicht von Verlagen veröffentlicht wird - sehr kompliziert, wenn nicht sogar unmöglich. Heute kann man sich viele der aktuellen CSTR's und einiges an Grauer Literatur bei einer der vielen digitalen Bibliotheken abholen. Wobei sich die Art der digitalen Bibliothek nach dem Inhalt der gewünschten Literatur richtet, zum Beispiel würde wohl niemand in NCSTRL nach Auszügen aus Goethes Faust suchen. Digitale Bibliotheken können an unterschiedlichen Standorten ihre Daten speichern, und für den Benutzer sind diese Daten trotzdem unter einer einheitlichen und leicht zu bedienenden Benutzungsoberfläche zusammengefasst, damit der Benutzer keine Probleme bekommt, wenn er mit der digitalen Bibliothek arbeitet. So sieht der Benutzer nur die graphische Oberfläche mit Hilfe seines Browsers, weil die digitalen Bibliotheken in den meisten Fällen eine HTML-Schnittstelle zur Verfügung stellen. Grundsätzlich sind alle hier vorgestellten Bibliotheken mit einem normalen Browser zu besichtigen.

131 9.1. EINLEITUNG 117 Dank der digitalen Bibliotheken können sehr große Datenmengen auf sehr begrenztem Raum konzentriert werden, durch die elektronische Speicherung kann ein schneller Zugriff auf die Inhalte der digitalen Bibliothek ermöglicht werden. Dadurch ist vielen Interessenten der Zugriff auf die digitale Bibliothek gleichzeitig möglich. Außerdem spielt bei digitalen Bibliotheken die Bequemlichkeit der heutigen Zeit eine große Rolle, man muss sich nicht mehr an die Öffnungszeiten seiner nahegelegenen Bibliotheken halten, und nicht jeder hat in seiner Nähe eine Bibliothek die den gewünschten Informationsbestand enthält. Man ruft heute also einfach bequem von zu Hause die gewünschten Informationen ab Arten von digitalen Bibliotheken mit Beispielen Die hier vorgestellten digitalen Bibliotheken sind wegen ihrer Nähe zur Informatik ausgewählt worden. Dabei hat sich eine Einteilung in drei Kategorien ergeben. In der Reihenfolge wie sie hier vorgestellt werden, findet man sie auch im nächsten Kapitel wieder. Als erstes kommen die digitalen Bibliotheken, die entweder von einer Fachgesellschaft betrieben werden, zu dieser Kategorie gehören: ACM und IEEE-CS, oder die von einem Verlag verwaltet werden, in diese Kategorie passt LINK sehr gut. Sowohl die Fachgesellschaften als auch die Verlage beabsichtigen natürlich mit ihrer jeweiligen digitalen Bibliothek die eigenen Zeitschriften, Dokumente, Bücher und weiteren Materialien schneller zu veröffentlichen, und ihr Material den eigenen Mitgliedern besser zugänglich zu machen. Trotzdem gehört meist zu ihrem Dokumentbestand auch Material das nicht direkt der Fachgesellschaft oder dem Verlag entstammt. Digitale Bibliotheken die größtenteils nur Graue Literatur und CSTR's verwalten, sind zum Beispiel: NCSTRL, NZDL und NDLTD. NDLTD - Networked Digital Library of Theses and Disertations, im Internet zu finden unter - sei hier nur am Rande erwähnt, in diesem Bericht findet NDLTD sonst keine weitere Erwähnung, weil es sich im Aufbau nicht sehr stark von den hier vorgestellten digitalen Bibliotheken unterscheidet. Als letztes folgen digitale Bibliotheken, die heterogene Informationsquellen, digitale Bibliotheken, unter einem einheitlichen System zusammenfassen. Dazu gehören MeDoc und UniCats. Aber auch NZDL und LINK binden noch weitere digitale Bibliotheken ein, trotzdem habe ich sie in den anderen Kategorien belassen. Am Beispiel von NZDL und LINK sieht man, dass es eigentlich keine exakte Einteilung in die einzelnen Kategorien gibt Vergleichskriterien Die im nächsten Kapitel vorgestellten digitalen Bibliotheken, wurden wegen ihrer Nähe zur Informatik ausgewählt. Verglichen werden sie aber nicht, weil bei einem solchen Vergleich die Objektivität leiden würde, deshalb werden die digitalen Bibliotheken einzeln vorgestellt. Die Vorstellung der einzelnen digitalen Bibliotheken läuft immer nach dem gleichen Schema ab.

132 118 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Als Erstes erfolgt eine Übersicht über die digitale Bibliothek, dazu gehören ein paar allgemeine Anmerkungen, was eventuell die Abkürzung bedeutet, wo die Seite im Internet zu finden ist, wann die Präsentation der digitalen Bibliothek gestartet wurde, und welche Ziele mit dieser digitalen Bibliothek verfolgt werden. Nach dieser Übersicht folgt dann eine kurze Beschreibung der Benutzerfreundlichkeit, dazu gehört die Beschreibung der grafischen Oberfläche und die Vorgehensweise beim Suchen der Informationen. Die Beschreibung der Benutzungsoberfläche wird nur sehr oberflächlich vollzogen, dafür kann man aber zu jeder vorgestellten Bibliothek den Link nachlesen, und sich die digitalen Bibliotheken im Netz anschauen. Deswegen sind auch keine Screenshots der einzelnen digitalen Bibliotheken beigefügt. Als Vorletztes folgt kurz eine Darstellung des Angebots der digitalen Bibliothek. Zum Angebot gehören: Informationen zum Inhalt der digitalen Bibliothek, die Formate und Dienste, die die digitale Bibliothek anbietet, und welche Teile der digitalen Bibliothek kostenlos und welche kostenpflichtig sind. Am Schluss kommen noch Bemerkungen zur Architektur der digitalen Bibliothek, das betrifft sowohl die Art der Speicherung der aufgenommenen Dokumente, genauer gesagt, wo werden die Dokumente gespeichert, und wie wird ein neues Dokument aufgenommen. In den abschließenden Anmerkungen werden noch einmal die vorrangigen Unterschiede der digitalen Bibliotheken herausgestellt. Anschließend folgt dann die Literaturliste, in der die benutzte Literatur aufgeführt wird.

133 9.2. DIGITALE BIBLIOTHEKEN Digitale Bibliotheken Fachgesellschaften und Verlage Die hier vorgestellten digitalen Bibliotheken werden entweder von einer Fachgesellschaft betrieben, zu dieser Kategorie gehören: ACM und IEEE-CS, oder von einem Verlag verwaltet, in diese Kategorie passt LINK sehr gut. Sowohl die Fachgesellschaften als auch die Verlage beabsichtigen natürlich mit ihrer jeweiligen digitalen Bibliothek die eigenen Zeitschriften, Dokumente, Bücher und weiteren Materialien schneller zu veröffentlichen und ihren Mitgliedern besser zugänglich zu machen. Trotzdem gehört meist zu ihrem Dokumentbestand auch Material das nicht direkt der Fachgesellschaft oder dem Verlag entstammt A C M Übersicht ACM steht für Association of Computing Machinery. Der Hauptsitz der " ACM ist in New York, dort befindet sich auch der Zentralrechner. Die ACM ist die Vereinigung der Informatiker in den USA, es gibt aber auch Mitglieder die aus anderen Ländern kommen. Außerdem existieren in einigen Ländern zu ACM gehörende Verbände, so gibt es in Deutschland das German Chapter von ACM, in dem sich die Deutschen Mitglieder befinden. Unter dem Link ist die ACM zu finden, unter diesem Link ist ebenfalls die digitale Bibliothek von ACM zu erreichen. Weitere Internet-Seiten sind in Europa, im Pazifikraum und an der Westküste geplant. Schon 1995 gab es bei der ACM erste Ideen für das elektronische Publizieren von Texten, aber erst seit 1997 ist die digitale Bibliothek von ACM im Internet zu finden. Das vorrangige Ziel der ACM ist es, seinen Mitgliedern Materialien von ACM und anderen Quellen elektronisch zur Verfügung zu stellen, und dies lässt sich am besten mit einer digitalen Bibliothek verwirklichen. Benutzerfreundlichkeit Nach Eingabe von landet man auf der Startseite der ACM, und nicht direkt in der digitalen Bibliothek von ACM. Wenn ein Benutzer auf search klickt, muss er aufpassen, denn wenn er auf der erscheinenden Search-Seite sucht, dann sucht er nicht in der digitalen Bibliothek von ACM, sondern in den WWW- Materialien von ACM. Man kann auch über das Anklicken von Digital Library auf der Startseite in der Suche der Digitalen Bibliothek landen. Für einen unerfahrenen Benutzer ist das vielleicht nicht sehr geschickt gelöst, denn man kann sich schnell mal auf den Seiten von ACM verirren. Aber auch der unerfahrene Benutzer dürfte mit den Seiten von ACM nach dem zweiten oder dritten Besuch keine Schwierigkeiten mehr haben. Wenn man dann auf der Suchseite angelangt ist, kann man seine Suchanfrage eingeben und nach folgenden Kriterien suchen: Titel, Volltext, Inhaltsangabe und noch einige weitere. Dann muss man sein Kennwort und das Passwort eingeben und erhält danach die Suchergebnisse. In den Suchergebnissen kann man sich dann vom Titel zur Inhaltsangabe und zum Volltext vorklicken. Wenn man kein Kennwort hat, also kein Mitglied der digitalen Bibliothek von ACM ist, kann man auf der Seite, die man erreicht, wenn man auf der Hauptseite von ACM Digital Library klickt, durch die einzelnen Zeitschriften von

134 120 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH ACM browsen. Allerdings bekommt man hier ohne Kennwort nur die Inhaltsangaben der Artikel. Jedweden Artikel kann man nur dann im Volltext lesen, wenn man ein Kennwort und das dazugehörige Passwort besitzt. Angebot Der hauptsächliche Inhalt von ACM sind natürlich ACM-Materialien, es sollen aber auch andere Materialien aufgenommen werden. Die Materialien von ACM umfassen momentan: -ca.9000 Volltext-Artikel von ACM - Journale, Magazine, ein Publikationsarchiv und Konferenzberichte seit ca.5000 Inhaltsverzeichnisse mit Literaturverweisen zu Zeitschriften von ACM -95%aller ACM Artikel und Proceedings seit Zeitschriften Das ergibt insgesamt mehr als Seiten Text, die in den Formaten HTML, PDF und PS angeboten werden. ACM bietet die Suche auf bibliographischen Daten an, das sind zum Beispiel: Titel, Autor, Bandangabe (welcher ACM Band), Ausgabejahr, Seitennummer und Schlüsselwörter, außerdem wird auch eine Volltextsuche angeboten. Durch die bibliographischen Daten entspricht die Suchmaschine dem heutigen Stand der Technik, außerdem werden die Suchergebnisse in Binders gespeichert, so sind sie jederzeit wieder abrufbar. Des weiteren sind die Artikel untereinander verlinkt, allerdings ist dieser Dienst erst in der Entwicklung, so dass momentan nur einige wenige Artikel miteinander verlinkt sind. Ein weiterer interessanter und nützlicher Dienst von ACM ist die Profilerstellung, die allerdings nur für Mitglieder, also für Leute mit Login und Passwort, angeboten wird. Bei der Profilerstellung wird ein Profil des Benutzers erstellt, und dieser Benutzer bekommt, wenn Artikel erscheinen, die seinem Interessenbereich abdecken, eine von ACM zugeschickt. In dieser Mail steht eine kurze Inhaltsangabe zu dem neuen Artikel und unter welche Adresse man den Artikel im Netz findet. Außerdem kann man sich als Mitglied noch an Artikeldiskussionen beteiligen. Kostenlos werden von ACM Inhaltsangaben, Bibliographie, Inhaltsverzeichnisse und die Navigation durch den Zeitschriftenbestand angeboten. Leider erhält man nur als Mitglied Zugriff auf die kompletten Texte, und auch die Suche kann man nur als Mitglied nutzen. Architektur Die Architektur von ACM ist stark zentralisiert, es läuft alles über den Hauptserver in New York. ACM ist momentan auch nur über zu erreichen, es sind aber weitere Seiten geplant I E E E - C S Übersicht Die IEEE-CS, gesprochen I tripple E ist der weltweit größte, unpolitische Berufsverband für Elektrotechniker und Informatiker. Die Abkürzung steht für " " Institut of Electrical und Eletronics Engineers - Computer Society _Unter der Adresse ist die IEEE-CS zu finden. Das Anfangsjahr der digitalen Bibliothek von IEEE war, wie bei ACM auch, Die Ziele von IEEE entsprechen denen von ACM, und zwar die Publikationen von IEEE den Mitgliedern zur Verfügung zu stellen.

135 9.2. DIGITALE BIBLIOTHEKEN 121 Benutzerfreundlichkeit Hier ist es genau so wie bei ACM, man landet auf der Seite von IEEE-CS und nicht direkt in der digitalen Bibliothek. Es gibt hier wie bei ACM zwei Möglichkeiten zur digitalen Bibliothek zu gelangen. Entweder über das anklicken von search wobei zu beachten ist, dass man sich noch nicht in der digitalen Bibliothek befindet, denn diese Option muss dann noch einmal extra angeklickt werden. Oder man muss sich erst einmal über das Publications Center zur Suche in der digitalen Bibliothek vorklicken. Ist man dann dort gelandet, kann man zwischen den Suchoptionen einfach (Autor, Titel, Inhaltsverzeichnis) und speziell (Volltextsuche) auswählen, und dort ist es dann möglich seine Suchanfrage einzugeben. Die einfache Suche ist kostenlos, aber die spezielle Suche fragt das Kennwort und das Passwort ab, mit dem man sich als Mitglied von IEEE identifiziert. Wenn man seine Abfrage abgeschickt hat, bekommt man eine Seite auf der die Ergebnisse aufgelistet sind. Diese Seite unterscheidet sich allerdings für die einfache und die spezielle Suche. Leider bekommt man bei der speziellen Suche nicht die Titel direkt auf den Bildschirm, sondern man bekommt die Trefferergebnisse in verschiedenen Zeitschriften. Von dort aus kann man sich dann weiter klicken, bis man Glück hat und die Informationen findet die man gesucht hat. Das Suchergebnis der einfachen Suche ist nicht so kompliziert, hier erhält man direkt die Titel der Dokumente. Von dort kann man sich zur Inhaltsangabe vor klicken und den Text dann downloaden. Angebot Zum Inhalt von IEEE gehören 17 Zeitschriften und etliche Berichte von IE- EE. Die Formate in denen diese Informationen abgespeichert sind, sind HTML, PS und PDF. Die Suche auf den bibliographischen Daten also nach Titel, Autor und Abstrakt sowie die Suche im Volltext wird von der digitalen Bibliothek von IEEE angeboten. Kostenlos ist bei IEEE die bibliographische Suche, sowie die Inhaltsangaben, Titel, Autoren und Inhaltsverzeichnisse. Kostenpflichtig sind die Suche im Volltext und die kompletten Dokumente. Architektur Ebenso wie bei ACM ist auch hier die Netzwerk-Architektur stark zentralisiert, nur über den Link gibt es einen Zugang zu IEEE L I N K Übersicht Von den in diesem Bericht vorgestellten digitalen Bibliotheken fällt LINK leicht aus der Reihe, denn der Inhalt von LINK umfasst nicht nur informatikspezifisches Material, sondern auch Materialien aus anderen Fachgebieten, so zum Beispiel aus den Gebieten: Chemie, Biologie, Physik, etc. LINK ist die digitale Bibliothek der Springer- Verlagsgruppe, deshalb wird sie auch LINK-Springer genannt. Was die Abkürzung LINK bedeutet, ist bei LINK selber nirgendwo erwähnt, vielleicht bezieht es sich einfach auf den Internet Ausdruck Link. Zu finden ist LINK unter zwei Adressen, als Erstes unter: link.springer.de, und als Zweites unter: link.springer-ny.com. Genauso wie die bereits vorgestellten digitalen Bibliotheken wurde LINK 1997 gestartet. Und zwar wurde sie da erstmals auf der CeBit dem Publikum präsentiert, seitdem ist LINK im Internet abrufbar. Benutzerfreundlichkeit Man landet direkt in der Digitalen Bibliothek von Springer, und kann nachdem man auf das Logo von LINK geklickt hat, auf der neuen Seite search

136 122 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH anklicken. Dann befindet man sich direkt in der Eingabemaske für die Suche, dort gibt man seine Suchanfrage an und bekommt die Ergebnisse seiner Anfrage zurück, diese werden mit Titel und Autor ausgegeben. Wenn man eins der Ergebnisse anklickt, bekommt man die Inhaltsangabe des Dokuments, von dort kann man dann den Artikel downloaden. Allerdings muss man sich vor dem Download wieder mit Kennwort und Passwort identifizieren. Angebot Folgende Materialien werden von LINK angeboten: lieferbare Bücher, von denen nur die Inhaltsverzeichnisse abrufbar sind, nicht aber die Volltexte Zeitschriften Papier-Publikationen -LNCS(Lecture Notes for Computer Science) - 11 Online Bibliotheken (die nach Fachbereich angewählt werden können) Außerdem sollen nicht nur elektronische Veröffentlichungen von Zeitschriften angeboten werden, sondern es soll auch der Zugriff auf Bücher, CD's und Software ermöglicht werden, wobei Demoversion von Software zum Download angeboten werden. LINK unterstützt viele verschiedene Formate dazu gehören: PDF, HTML, TEX, LATEX, Bild- Formate, Sound-Formate, Video-Formate, PDB (Darstellung von chemischen Strukturen) und WRL (Virtual Reality). LINK bietet wie die anderen digitalen Bibliotheken verschiedene Dienste an. Schon bei der Suche gibt es mehrere Arten von Suchmöglichkeiten: LINK Power Search: Die strukturierte Suche in definierten Feldern, LINK Search: Die Suche in den bibliographischen Beständen, LINK Global Search: Die Suche im gesamten Datenbestand. Ein weiterer Dienst der angeboten wird ist LINK Alert. LINK Alert ist ein kostenloser Alerting Service für Mitglieder, die dann über neue Beiträge, in einer Zeitschrift oder einem Artikel der direkt online erscheint, automatisch per informiert werden. Diese enthält das Inhaltsverzeichnis des Beitrags und die Adresse unter dem der Artikel abgerufen werden kann. Des weiteren wird noch ein monatliches Newsletter angeboten. LINK bietet die Inhaltsverzeichnisse, Inhaltsangaben, Probeseiten und -kapitel sowie eine Testwoche, in der man wie ein normales Mitglied agieren kann kostenlos an, so dass man bei LINK nur für die kompletten Dokumente bezahlen muss. Architektur Die Architektur ist genauso aufgebaut, also zentralisiert, wie bei ACM und IEEE. Im Gegensatz zu ACM und IEEE bietet LINK zwei Links an unter denen man LINK abrufen kann.

137 9.2. DIGITALE BIBLIOTHEKEN Graue Literatur und CSTR Digitale Bibliotheken deren Dokumentbestand größtenteils nur Graue Literatur und CSTR's verwalten, sind zum Beispiel die hier vorgestellten: NCSTRL und NZDL. CSTR's sind Computer Science Technical Reports und Graue Literatur ist Literatur (zum Beispiel: Vorlesungsmitschriften von Professoren) die in den meisten Fällen nicht von Verlagen veröffentlicht wird N C S T R L Übersicht NCSTRL umfasst eine große Sammlung von CSTR, sie werden alle komplett kostenlos zur Verfügung gestellt. Angefangen hat NCSTRL mit den CSTR's von WA- TERS (Wide Area Technical Reports Services) und CCSTR (Cornell Computer Science Technical Reports), inzwischen hat sich NCSTRL aber noch stark vergrößert. NCSTRL steht für " Networked Computer Science Technical Reference Library, NCSTRL wird " Ancestral gesprochen. Es gibt zwei Arten von Zugangsservern, entweder den Zugang über den zentralen Server: oder über einen der verschiedenen lokalen Server, wie zum Beispiel der NCSTRL Server der Universität Oldenburg der unter ncstrl.offis.uni-oldenburg.de zu finden ist. Außerdem kann man NCSTRL auch über MeDoc abfragen. Schon seit 1994 ist NCSTRL im Internet vertreten. Die Vernetzung von einzelnen Anbietern, die fachbezogene Informationen anbieten, ist eines der Ziele von NCSTRL. So soll das System einfach zu erweitern sein, das heißt neue Funktionen und Anbieter sollen eingebunden werden, ohne dass das System jedes Mal verändert werden muss. Außerdem sollen die Inhalte jederzeit der Öffentlichkeit zur Verfügung stehen, deshalb ist bei NCSTRL auch keine Anmeldung erforderlich. Des weiteren soll es einen zentralen Zugang unter einer einheitlichen Benutzungsoberfläche geben. Für all diese Ziele war NCSTRL sozusagen ein Testprogramm, das gezeigt hat, dass so etwas durchführbar und hilfreich ist. Benutzerfreundlichkeit Man landet bei Eingabe der Adresse für den zentralen Server von NCSTRL direkt in der Suchoption, dort gibt man seine Suchanfrage ein. Das Suchergebnis gibt jeweils den Titel, den Autor, die DokumentID und die Institution, von der das Dokument stammt, an. Jetzt kann man einfach den gewünschten Text anklicken und man erhält die Inhaltsangabe. Dort klickt man auf Download oder man wählt zuerst ein Format aus, in dem man den Text speichern möchte. Angebot Inhalte von NCSTRL sind: Graue Literatur, CSTR's und Zeitschriftenartikel. Die Artikel werden in den Formaten: HTML, PS (die meisten Dokumente sind in diesem Format abrufbar ), PDF, TIFF und GIF. Die Suche von NCSTRL bietet an, dass man entweder auf allen bibliographischen Daten oder auf speziellen bibliographischen Daten (Autor, Titel, Inhaltsangabe) sucht. Außerdem kann man die Reihenfolge, in der die Ergebnisse aufgelistet werden, selbst bestimmen. Wer sich als Mitglied einträgt, wird in eine Mailingliste aufgenommen, so erhält man immer die neusten Informationen über neue Artikel. Abschließend sei noch erwähnt, dass der komplette Datenbestand, den NCSTRL anbietet, kostenlos ist.

138 124 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Abbildung 9.1: NCSTRL-Architektur Architektur NCSTRL ist eine offene Architektur (Abb. 9.1) von interagierenden Sites. Jede dieser Sites betreibt einen digitale Bibliotheksserver und unterstützt den Zugriff auf alle teilnehmenden Institutionen (diese fügen Dokumente zur Bibliothek hinzu). Jeder digitale Bibliotheksserver hat drei Aufgaben: - Bereitstellung einer Dokumentverwaltung, die für die Speicherung und den Zugriff auf Dokumente zuständig ist - Bereitstellung einer Indexverwaltung, die eine verteilte Suche ermöglicht - Bereitstellen einer Benutzungsschnittstelle, über die die Nutzer Zugriff auf NCSTRL haben Meta-Server stellen zusätzlich Informationen über die an NCSTRL beteiligten Institutionen und deren Index- und Dokumentverwaltungen bereit. In NCSTRL wurden alle Technical Reports von WATERS und CCSTR (Cornell Computer Science Technical Reports) übernommen. NCSTRL benutzt die technischen Entwicklungen von zwei Projekten, und zwar sind diese Projekte: das CSTR Projekt (Computer Science Technical Reports) und das WATERS Projekt (Wide Area Technical Report Services). Das DIENST-Protokoll ist ein offenes Protokoll, damit NCSTRL-Sites miteinander kommunizieren können. Da dieses Protokoll einheitlich ist, ist das System von NCSTRL beliebig erweiterbar, beispielsweise durch weiter entwickelte Index- oder Suchverfahren. Und WATERS bietet die Suche auf bibliographischen Daten an. Der Suchvorgang nach einem Dokument läuft folgendermaßen ab:

139 9.2. DIGITALE BIBLIOTHEKEN 125 Abbildung 9.2: NCSTRL-Regional Nutzeranfragen werden über das HTTP und CommonGateInterface durch denbrowser an die Benutzungsschnittstelle weitergereicht. Die Benutzungsschnittstelle leitet die Anfrage parallel entweder an die vom Nutzer zuvor selektierten Sites oder alle registrierten Sites weiter. Jede dieser Sites führt eine Abfrage auf ihrem Index-Server durch und sendet eine Liste mit zutreffenden Dokumentreferenzen zurück. Der Benutzer bekommt dann die Gesamtliste auf dem Browser zu sehen. Wählt er ein Dokument aus so kommt er zum entsprechenden Repository-Server der die MetaDaten des Dokuments zurück liefert. Die MetaDaten bestehen aus bibliographischen Angaben, wie Autor, Titel, Zusammenfassung und Link auf die Adresse der Download-Version. Das System soll so stabil und fehlertolerant sein, gegenüber dem Ausfall einzelner Komponenten oder Leitungsunterbrechungen. Das weltweit verteilte Netz wird in einzelne Regionen (Nordamerika, Mitteleuropa,...)eingeteilt. Bei der Partitionierung sollten sowohl Engpässe auf globalen Datenleitungen als auch Konzentrationen des Netzverkehrs berücksichtigt werden. Eine Region (Abb. 9.2) besteht aus einem regionalen Meta-Server (RMS) mindestens einem Merged Index Server (MIS) und verschiedenen Standard Sites (StS). Regionale Meta Server stellen Informationen über alle an NCSTRL angeschlossenen Institutionen bereit. Sie erhalten diese Informationen in regelmäßigen Abständen von einem zentralen Master Meta Server (MMS) auf dem die Daten manuell eingegeben werden müssen. Anfragen an eine Site, innerhalb einer Region, werden direkt an die betreffenden Sites geschickt, während Anfragen an eine außerhalb liegende Site an einen MIS gesendet werden. Der MIS enthält alle Indexe außerhalb der Region liegender Sites. Institute die sich anschließen wollen, haben die Wahl zwischen NCSTRL-lite und NCSTRL-standard (Benutzung der Server Software). Es gibt also diese zwei Möglichkeiten der Organisation: Standard-Server: erlaubt indexing, suchen, eine lokale Benutzungsschnittstelle und bietet die Möglichkeit eine eigene Suchmöglichkeit zu benutzen.

140 126 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Lite-Server: erlauben eine einfache FTP-Seite von Technical Reports und das Schicken der bibliographischen Daten an einen speziellen Server N Z D L Übersicht NZDL benutzt mehrere digitale Bibliotheken als Arbeitsgrundlage, außerdem es sind auch im Netz verstreute CSTR's eingebunden, sofern sie NZDL bekannt sind. Das Projekt wurde von der Universität in Waikato auf New Zealand ins Leben gerufen, deshalb bedeutet die Abkürzung NZDL New Zealand Digital Library. Seit " 1995 ist dieses Projekt unter der Adresse im Internet zu finden. Eines der Hauptziele von NZDL ist nicht der Aufbau einer neuen digitalen Bibliothek, sondern die Weiterentwicklung der Techniken auf denen digitalen Bibliotheken basieren, sowie deren Verbreitung im Internet. Dazu gehört zum Beispiel die Dokumentaufnahme, die bei NZDL später vollständig automatisch ablaufen soll. Momentan wird zwar schon ein großer Teil der Dokumente automatisch aufgenommen, aber wenn zu den Dokumenten bibliographische Daten existieren, werden diese noch immer verwendet. Dies erhöht momentan immer noch den Grad der Organisation innerhalb der digitalen Bibliothek. Durch eine gute Organisation ergibt sich auch immer eine bessere und zuverlässigere Suche auf dem Datenbestand. Benutzerfreundlichkeit Auf der Seite von NZDL bekommt man mehrere digitale Bibliotheken zur Auswahl, sofern man eine dieser digitale Bibliotheken ausgewählt hat, kann man seine Suchparameter eingeben und bekommt dann die Ergebnisse zurück. Als Ergebnisse werden dann ausgegeben der Titel, der Autor und ob eventuell eine Inhaltsangabe vorhanden ist. Ist eine Inhaltsangabe vorhanden kann man diese erst lesen, wenn keine Inhaltsangabe vorhanden sein sollte, dann kann man sich das Dokument direkt von der angegebenen Adresse herunterladen. Angebot Insgesamt umfasst NZDL CSTR's, Abbildungen, das sind so in etwa 35GB an PS-Dateien, das sind wiederum in etwa Seiten (ca. 130 Millionen Wörter). Von dieser großen Datenmenge liegt aber nur 1GB auf dem Server der NZDL, in Waikato. Wie schon LINK, fällt NZDL etwas aus der Reihe, weil NZDL auch Materialien eingebunden hat, die nicht Informatik bezogenen sind. So zum Beispiel die digitalen Bibliotheken des Gutenberg Projektes, eine music library, BBC Online und noch einige weitere digitale Bibliotheken. Außerdem will NZDL in Zukunft weitere digitale Bibliotheken einbinden. Folgende Formate werden von NZDL unterstützt: PS (in den meisten Fällen), PDF, DVI, ASCII, RTF, HTML, SGML. Gesucht wird auf den Volltexten, jeweils in dem Bereich den man vorher auswählt hat. Das komplette Angebot von NZDL ist kostenlos. Architektur Eine der Hauptfragen für digitale Bibliotheken: Wo sollen die Informationen gespeichert werden? Zentral oder Verteilt. Daraus leitet sich das Problem der Verteilung ab, wann ist man zu sehr verteilt, das heißt wie viel der Informationen muss man auf dem eigenen Server unterbringen. Bei NZDL wurde so entschieden (Abb. 9.3), dass

141 9.2. DIGITALE BIBLIOTHEKEN 127 Abbildung 9.3: NZDL-Architektur der Index und die Suchmaschine auf dem NZDL-Server liegen, nicht aber die Originaldokumente, diese werden auf den Originalservern belassen. Zu jedem Dokument existiert neben dem Index noch ein ca. zweiseitiges Faksimile. So kann jeder Benutzer den Titel, Autor und die Inhaltsangabe anschauen, sowie einen Einblick in die Textform nehmen. Die Abwesenheit von bibliographischer Katalogisierung (Indexen) erschwert die Suche nach einem bestimmten Dokument, wenn man nicht den Namen und Titel eingibt. Außerdem sind bestimmte Artikel die schon länger bei NZDL liegen evtl. nicht mehr zugreifbar, weil sie eventuell von dem Originalserver, auf dem sie früher lagen, entfernt wurden. Außerdem ist das Fehlen von konventionellen bibliographischen Information ein großer Mangel bei der Suche auf dem Datenbestand. NZDL möchte vorerst noch die konventionellen bibliographischen Informationen benutzen, denn diese erhöhen den Grad der Organisation in der digitalen Bibliothek erheblich. Aber NZDL ist nur an öffentlichen Dokumenten interessiert, da die Aufnahme von kostenpflichtig Dokumenten zu umständlich wäre, leider existieren bei den öffentlichen Dokumenten meistens keine bibliographischen Daten. CSTR's liegen überall im Netz verstreut. NZDL will diese Dokumente auffindbar machen, und sie dem Benutzer von NZDL, über eine einheitliche Benutzungsschnittstelle, zugänglich machen, so dass der Benutzer die gewünschten Dokumente einfach und ohne große Suche finden kann, und sich nicht durch eine Menge von überflüssigen Materialien arbeiten muss. Einer der Vorteile von NZDL ist, dass nicht sehr viel Platz auf dem eigenen Server benötigt wird, und dass die Internetkosten nicht zu groß werden. Anbieter wissen manchmal gar nicht, dass ihre Dokumente von NZDL verwaltet werden, weil keine Zusatzsoftware, Archive oder ähnliches, auf Anbieterseite, benötigt werden. Es ist aber sehr hilfreich eine komplette Kopie des Textes (in ASCII, nicht in PS) in New Zealand zurückzubehalten. Da diese sehr hilfreich zum Browsen sein kann. Der Suchvorgang läuft folgendermaßen ab: Der Benutzer stellt eine Anfrage an die NZDL (in New Zealand), der Webserver befragt die Index Collection und gibt dem Benutzer eine Dokumentliste zurück. Will der Benutzer jetzt den Originaltext, dann holt sich der Webserver das PS-File von der gespeicherten Adresse und überträgt sie dem Benutzer. Die Index Collection holt sich ihre Daten von den Servern in den USA, diese wiederum holen sich die Indexe von Rechner auf denen die CSTR liegen. So braucht die NZDL nicht erst alle Dokumente herunterzuladen, sondern das machen die Server in den USA. Die Server laden sich die Technical Reports runter und erstellen ein Faksimile und den Volltext des Dokuments im ASCII-Format (Abb. 9.4),

142 128 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Abbildung 9.4: NZDL-Text dann löschen sie das Original wieder von ihrem Server. Dieser Server schickt seine Daten dann an die NZDL. Technische Reports sind über viele Seiten im Internet erreichbar. Neue Dokumente werden nicht per Hand bearbeitet, bzw. vorher von den Autoren bearbeitet, sondern es werden die bibliographischen Daten automatisch erstellt. Dazu muss die Suchmaschine der digitalen Bibliothek einige Annahmen treffen, wie zum Beispiel: man nimmt an das der Autor immer am Beginn eines Dokuments steht (also auf der ersten Seite). Ein großer Nachteil von NZDL ist die Qualität der Suchergebnisse, da NZDL keine bibliographischen Daten verwendet, die von Hand erstellt wurden, sondern Daten, die mit Programmen extrahiert wurden. Wenn man zum Beispiel eine digitale Bibliothek verwendet, die auf bibliographischen Daten arbeitet, so wie NCSTRL, dann bekommt man bei Eingabe von Java einen Text, in dem es um Java geht, falls die bibliographischen Daten zuverlässig erstellt wurden. Benutzt man aber eine digitale Bibliothek wie NZDL und gibt dort Java ein, bekommt man auch Texte in denen Java nur kurz erwähnt wird, die aber sonst nicht näher mit Java zu tun haben. Ein weiterer Nachteil bei NZDL ist die Abhängigkeit vom Zentralserver auf Waikato, fällt dieser mal aus, so gibt es keine NZDL mehr. Jedenfalls solange nicht bis der Server wieder läuft.

143 9.2. DIGITALE BIBLIOTHEKEN Einbindung heterogener Informationsquellen in eine einheitliche Systemwelt Zu den digitalen Bibliotheken, die heterogene Informationsquellen unter einem einheitlichen System zusammenfassen, gehören MeDoc und UniCats. Aber auch digitale Bibliotheken wie NZDL und LINK binden noch weitere digitale Bibliotheken ein, trotzdem wurden sie schon vorher aufgeführt, weil sie besser in die anderen Kategorien passen MeDoc Übersicht Mit Hilfe von MeDoc ist es beabsichtigt, den Übergang vom gedruckten zum elektronischen Informationsmaterial zu fördern. MeDoc ist ein System, in dem fachspezifische Informationen, aus der Informatik, gespeichert, recherchiert, abgerufen und gelesen werden können. Zum großen Teil wurde MeDoc in Java implementiert. Die Abkürzung Me- Doc steht für Multimedia Electronic Documents. Zu Erreichen ist MeDoc im Internet " unter der Adresse: pfirsich.offis.uni-oldenburg.de/servlets/medoc. Das MeDoc Projekt ist seit 1997 online. Da die Ziele von MeDoc sehr vielfältig sind, und man diese besser in der entsprechenden Literatur [ABdKe98] nachlesen kann, werden hier nur ein paar der Ziele genannt. MeDoc soll ein volltextbasierter Informationsdienst bzw. Publikationsdienst sein. So soll die Übertragung kostenpflichtiger Daten gegen das Verfälschen, Abhören und sonstige Beeinflussung gesichert sein. Außerdem sollte eine Oberfläche bereitgestellt werden, die leicht zu handhaben und zu bedienen ist. Ein weiteres Ziel war die Schaffung eines Informationsverwaltungssystems, das auf verteilten, heterogenen Informationsquellen recherchiert. Dazu muss eine spezielle Abfragesprache erstellt werden. Außerdem sollten die Datenbestände erweiterbar sein. Benutzerfreundlichkeit Man landet bei Eingabe der oben angegebenen Adresse direkt bei MeDoc, dort kann man sich als Gast oder als Nutzer einloggen, als Nutzer allerdings nur dann, wenn man ein Kennwort und ein Passwort hat. Dann gibt man in der Suchmaske seine Anfrage ein, und man bekommt sofort die ersten Ergebnisse, die man aber mit der Zeit aktualisieren kann, immer dann wenn ein anderer Server geantwortet hat. Als nächstes kann man die Ergebnisse anklicken, die mit Titel und Autor angegeben sind. Und man kann sich die Inhaltsangabe oder das Inhaltsverzeichnis anschauen. An dieser Stelle kommt man nur als Nutzer weiter, denn wenn man nicht gerade ein Buch auswählt, dass zur Zeit als Leseprobe zur Verfügung steht, muss man sich als Nutzer identifizieren. Angebot Zum Inhalt von MeDoc gehören Bücher, Fachliteratur, die im Volltext gespeichert wird, und fachspezifische digitale Bibliotheken die an MeDoc angegliedert sind, dazu gehören zum Beispiel: NCSTRL, Achilles und weitere digitale Bibliotheken. Die Formate, die MeDoc unterstützt, sind hauptsächlich HTML und PDF. Einige der Dienste die MeDoc anbietet, sind die Navigation durch den Dokumentbestand und die Suche im Dokumentbestand, nach Autor, Titel oder im gesamten Volltext. Kostenpflichtig sind zum größten Teil die Bücher die angeboten werden. Die Suche, die Inhaltsangaben sowie die Inhaltsverzeichnisse zu den Büchern, Probekapitel, Dokumentteile und einige wenige Bücher sind komplett kostenlos.

144 130 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Abbildung 9.5: MeDoc-Architektur Architektur MeDoc ist eine Drei-Schichten-Architektur (Abb. 9.5), bestehend aus der Anbieteranbindungsschicht, der Nutzeranbindungsschicht und der Vermittlungsschicht. Die Anbieteranbindungsschicht kapselt verschiedene heterogene Anbietersysteme, auf denen die Volltexte liegen. Dadurch erfolgt jedes Mal der gleiche Zugriff durch die Nutzeranbindungsschicht. Die Anbieteranbindungsschicht wird vom Anbieteragenten unterstützt, wobei der Anbieteragent für jeweils ein System installiert ist. Der Anbieteragent meldet sich bei den Brokern an. Er nimmt die Aufträge vom Nutzeragenten an und leitet diese Aufträge weiter an das Anbietersystem. Dann erhält der Anbieteragent die Ergebnisse vom Anbietersystem zurück. Die Ergebnisse werden in das MeDoc-Schema transformiert, und dann weitergeleitet an den jeweiligen Nutzagenten. Die Nutzeranbindungsschicht enthält das Nutzersystem, das die Schnittstelle zum Benutzer ist. Zur Nutzeranbindungsschicht gehört der Nutzeragent, der für eine bestimmte Anzahl an Nutzer zuständig ist und lokal installiert wird. Der Nutzeragent verwaltet die Nutzer und stellt den Nutzern eine Eingabemöglichkeit für ihre Anfragen zur Verfügung. Diese Anfragen werden dann ausgewertet und an die anderen Komponenten im System weitergeleitet. Dann bekommt der Nutzeragent die Ergebnisse zurück, diese Ergebnisse werden verwaltet und gespeichert. Als letztes werden dem Nutzer die Ergebnisse visualisiert. Die Vermittlungsschicht vermittelt zwischen den Nutzern und den Anbietern bei Suchanfragen. Zur Vermittlungsschicht gehört der Broker, der bei einer Anfrage die in Frage

145 9.2. DIGITALE BIBLIOTHEKEN 131 kommenden Anbieter auswählt. Die einzelnen Komponenten bilden ein kommunizierendes System, bei dem die Kommunikation durch das MeDoc-Protokoll erfolgt. Der Benutzer wird folgendermaßen unterstützt: Er weiß nicht wo Informationen liegen, dann kann er sich über den Nutzeragenten an einen Broker wenden, und diesem seine Anfrage mitteilen. Der Broker ermittelt dann das geeignete Anbietersystem und dieses gibt seine Informationen zurück an den Broker, die dann der Benutzer vom Broker erhält UniCats Übersicht Es existiert momentan ein vielfältiges Angebot an digitalen Bibliotheken, der Nachteil ist, wenn man breit gefächerte Informationen zu einem Thema sucht, dann musste man alle diese digitalen Bibliotheken durchsuchen, das kostet Zeit und Nerven. Der Ansatz des UniCats-Projektes ist es den Benutzer in verteilten heterogenen digitalen Bibliotheken zu unterstützen. Die Abkürzung UniCats steht für " auniversal Integration of Catalogues based on an Agent-supported Trading and wrapping system oder kurz " a Unified Catalogues. Derzeit sind unter dem Link: wwwipd.ira.uka.de nur Informationen über UniCats zu finden, denn bisher gibt es nur einen Prototypen, der noch nicht im Internet zur Verfügung steht. Das Ziel von UniCats ist das Aufsetzen eines übergeordneten Suchsystems auf andere vorhandene digitale Bibliotheken, das sind zum Beispiel: NCSTRL, MeDoc, LINK und viele weitere. Die Vorteile bei diesem Verfahren wären, dass die Quellen autonom bleiben, sie werden also vom UniCats System nicht beeinträchtigt, der Benutzer braucht die einzelnen Quellen jedoch nicht zu kennen und dadurch ergeben sich für ihn eventuell mehrere Beschaffungsalternativen, denn vielleicht gibt es einen Artikel bei einer kostenlosen digitalen Bibliothek und einen gleichen Artikel bei einer der digitalen Bibliotheken, wo dieser Artikel nicht kostenlos wäre. Außerdem muss der Benutzer nicht bei jeder digitalen Bibliothek Mitglied sein, er kann sich die Suchergebnisse heraussuchen die ihn am ehesten ansprechen und die er bei einer der digitalen Bibliotheken findet, bei denen er Mitglied ist. Benutzerfreundlichkeit Es existiert nur eine Vorabseite mit Information, momentan gibt es noch kein lauffähiges Programm im Internet. Man kann sich nur entsprechende Informationen über UniCats besorgen. Die Oberfläche von UniCats gibt es in zwei und auch in dreidimensionaler Ausführung, die dreidimensionale Oberfläche basiert auf dem Spiel Quake, die zweidimensionale Oberfläche ist den Oberflächen der bisher vorgestellten digitale Bibliotheken ähnlich. Angebot Bei UniCats richtet sich sowohl der Preis eines Dokuments, als auch die Inhalte und Formate nach dem, was die eingebundenen digitalen Bibliotheken anbieten, und in welchen digitalen Bibliotheken der Benutzer suchen will. Die Hauptaufgabe von UniCats ist die Suche auf den verschiedenen angegliederten digitalen Bibliotheken und nicht die Bereitstellung von Dokumenten.

146 132 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH Abbildung 9.6: UniCats-Architektur Architektur Die Architektur von UniCats (Abb. 9.6) umfasst drei Komponenten, das sind der Benutzeragent, der Trader und der Wrapper. Die Aufgaben des Benutzeragenten sind, dem Benutzer eine einheitliche Oberfläche zu bieten und ihm bei der Anfrageformulierung zu unterstützen. Der Benutzeragent zerlegt die Anfragen des Benutzers in verschiedene Anfragen, die die Interessen des Benutzers repräsentieren. Der Vorteil für den Benutzer ist das dadurch der Kosten- und Zeitaufwand minimiert wird. Der Trader vermittelt dann zwischen dem Benutzeragenten und dem Wrapper. Seine Aufgabe ist es den Server zu finden der den Benutzerwünschen am ehesten entspricht. Der Wrapper hat die Aufgabe eine Anfrage in die Provider(server)- oder Benutzer(server)sprache zu übersetzen. Außerdem meldet sich der Wrapper bei einem oder mehreren Tradern an und er erhält dabei Angaben vom Trader, über Menge, Inhalt, Sprache und Kostenmodell der eingegliederten digitalen Bibliotheken. Eine Suchanfrage läuft dann folgendermaßen ab: Der Benutzer stellt seine Anfrage per HTTP an den Benutzeragenten, dann fragt der Benutzeragent den Trader. Darauf antwortet der Trader mit einer Liste von wichtigen Servern und jeweils die wichtigsten Fakten über diese Server. Der Benutzeragent gibt die Anfrage an den Wrapper weiter, der Wrapper holt sich die Informationen von den einzelnen Providern. Der Wrapper antwortet jetzt dem Benutzeragenten, dieser fasst die Suchergebnisse in eine Suchantwort und übermittelt sie dem Benutzer. Als letztes kann der Benutzer dann wählen, ob er das jeweilige Dokumente von der digitalen Bibliotheken die es anbietet, holen möchte oder nicht.

147 9.3. ABSCHLIEßENDE ANMERKUNGEN Abschließende Anmerkungen Nach der Vorstellung der einzelnen digitalen Bibliotheken, sieht man wie schwer sie miteinander zu vergleichen sind, denn über allem, also dem Aufbau der Architektur, der Benutzerfreundlichkeit der digitalen Bibliothek, dem Anteil an kostenlosen und kostenpflichtigen Informationen, der Art der Speicherung und der Aufnahme von Dokumente und sogar welche Formate die angebotenen Dokumente besitzen, steht die Art der Informationen die man sucht. Wenn man einen Artikel von ACM sucht, dann wird man wahrscheinlich kein großes Glück bei IEEE haben, egal wie sehr einem der Aufbau von IEEE gefällt oder der von ACM missfällt. Also richtet sich für den Benutzer die Wichtigkeit einer digitalen Bibliothek, vor allem nach dem Inhalt, denn es gibt keine " guten oder " schlechten Inhalte, sondern nur die eigene Anfrage betreffende relevante Inhalte. Wenn man die Benutzerfreundlichkeit der einzelnen digitalen Bibliotheken miteinander vergleicht, dann sieht man, dass der Unterschied nicht sehr groß ist, wenn man mal die 3D-Oberfläche des UniCats-Projektes nicht weiter beachtet. Bei allen digitalen Bibliotheken ist eine normale (2D) Oberfläche vorhanden, die man mit einem normalen Browser betrachten kann. Auf dieser Oberfläche muss man sich mehr oder wenig umständlich bis zu den Suchoptionen vorarbeiten. Ist man soweit gelangt, gibt man seine Suchanfrage ein, und man kann dann die Ergebnisse durchsuchen. Für einen Anfänger ist das bei den einzelnen digitalen Bibliotheken nicht ganz unkompliziert, aber wenn er eine der digitalen Bibliotheken zwei- bis dreimal besucht hat, dürfte auch der Anfänger keine Schwierigkeiten mehr mit der Bedienung haben. Was sich bei den einzelnen digitalen Bibliotheken noch unterscheidet, ist die Anzahl der Suchoptionen, beziehungsweise der Suchparameter. Ein weiterer wichtiger Unterschied ist noch, ob man sich bei einer digitalen Bibliothek anmelden muss oder ob man dies nicht muss. Momentan ist es so, dass man sich nur bei kostenpflichtigen Inhalten anmelden muss. Der Vorteil einer Anmeldung könnte aber auch genutzt werden, um bei einer digitalen Bibliothek wie zum Beispiel NCSTRL, ein Benutzerprofil und eine Suchhistorie zu erstellen. Dies ist bei einer digitalen Bibliothek, bei der man sich nicht anmelden muss, nicht möglich. Es kann jedoch sein das eine Anmeldung einige Benutzer abschreckt, weil es doch, wenn auch nur gering, ein zusätzlicher Zeitaufwand ist. Als letztes sollen noch die internen und architektonischen Unterschiede erwähnt werden. NZDL zeigte ein neues Schema für eine digitale Bibliothek, denn Dokumente können auch aufgenommen werden, wenn keine bibliographischen Informationen vorhanden sind, denn hier werden die Dokumente vollständig automatisch aufgenommen. Dies wirkt sich momentan leider noch auf die Qualitätder Suchergebnisse aus. Die Speicherung von Dokumenten zeigte zwei große Unterschiede, einmal die Speicherung auf speziellen Servern, die der digitalen Bibliothek gehören, wo viele Dokumente zusammengelegt werden, oder aber die Beibehaltung der Dokumente auf dem Originalserver, wobei der Server der digitalen Bibliothek nur die wichtigsten Daten der Dokumente speichert. In der Architektur gibt es die zwei Richtungen: zentral und dezentral. Sehr zentral liegen die Daten bei ACM, IEEE und LINK, dezentral liegen sie bei NCSTRL, MeDoc, UniCats und NZDL. Allerdings sind diese Unterschiede für den Benutzer nicht sichtbar, und mit einigen Ausnahmen, auch nicht wichtig. Wie schon Eingangs erwähnt richtet sich der wichtigste Unterschied auf den Inhalt

148 134 KAPITEL 9. DIGITALE BIBLIOTHEKEN IM VERGLEICH der digitalen Bibliothek, es nützt nichts wenn man von der Oberfläche begeistert ist, aber die gesuchten Informationen über diese digitale Bibliothek nicht bekommen kann. Daher sollte sich jeder nach seinen eigenen Anforderungen die entsprechende digitale Bibliothek aussuchen.

149 Kapitel 10 Information Retrieval Werner Willms Diese kurze Ausarbeitung zum Thema Information Retrieval im Rahmen der Projektgruppe "Entwicklung von Werkzeugen für Digitale Bibliotheken" an der CvO-Universität Oldenburg soll die wichtigsten Grundlagen der Informationswiedergewinnung digitaler Daten darstellen. Nach einer kurzen Einleitung wird auf das Information Retrieval bei Texten und die dadurch entstehenden Probleme eingegangen. Anschließend werden grundlegende Ansätze des Information Retrieval aufgezeigt und die heute wichtigsten - unter anderem das Boolesche Retrieval - inklusive deren Vor- und Nachteile erläutert. Abschließend wird eine Bewertung gegenwärtiger Systeme vorgenommen, sowie ein Ausblick auf zukünftige Entwicklungen gewährt. 135

150 136 KAPITEL 10. INFORMATION RETRIEVAL 10.1 Einleitung In den letzten Jahrzehnten hat sich in unserer Gesellschaft ein dramatischer Wandel hin zur so genannten Informationsgesellschaft vollzogen. Das zentrale Element in dieser Gesellschaft ist natürlich die Information, die in vielen Variationen auftreten kann. Begünstigt durch das immer weiter wachsende Internet und der günstigen verfügbaren Technik ist es quasi jedermann möglich, auf einen riesigen Pool von Informationen jederzeit zuzugreifen. Das zentrale Problem hierbei jedoch ist, aus diesem Informations-Pool auch die Informationen herauszupicken, die man gerade benötigt. Standard-Datenbanken, wie z.b. jene, die sich der Anfrage-Sprache SQL bedienen, sind für eine gezielte Suche nach gespeichertem Wissen denkbar ungeeignet, da sie einerseits in der Regel schwer zu bedienen sind, andererseits von ihrem Aufbau her gar nicht für eine solche Suche konzipiert wurden. Um das Problem der Suche in einem riesigen Pool an Informationen zu lösen, wurden Systeme entworfen, die sich gänzlich von den Standard-Datenbanken unterscheiden: die so genannten Information Retrieval Systeme. Diese Systeme versuchen, das riesige Angebot an Information zu ordnen und stellen Hilfsmittel bereit, aus diesem Angebot eine gewünschte Information zu extrahieren, ohne den Benutzer eines solchen Systems völlig zu überfordern. Jeder, der an das Internet angeschlossen ist, hat in der Regel schon einmal mit Information Retrieval Systemen gearbeitet: die großen Suchmaschinen (AltaVista, Lycos etc.) im Internet sind nämlich nichts anderes als Information Retrieval Systeme. Den Begriff Information Retrieval und dessen Hintergrund etwas verdeutlichen kann die (nicht ganz korrekte) Übersetzung: " Inhaltliche Suche in Literatur-Datenbanken, wobei allerdings schon eine Einschränkung in Kauf genommen wird: Information Retrieval ist nämlich keineswegs nur auf Literatur-Datenbanken beschränkt, obwohl dies zur Zeit das Hauptaufgaben-Feld des Information Retrieval ist. Allgemein lässt sich sagen, dass Information Retrieval Systeme versuchen, den Benutzer bei seiner Informationssuche effektiv zu unterstützen. Dass dies im Allgemeinen alles andere als einfach ist, und dass es große Unterschiede bezüglich der Qualität der gefundenen Informationen gibt, wird sich in den nächsten Kapiteln herausstellen Beispiel von IR anhand einer Literatur-Datenbank Wie bereits angesprochen, ist die inhaltliche Suche in Literatur-Datenbanken das zur Zeit vorherrschende Betätigungsfeld des Information Retrieval. Literatur-Datenbanken bestehen in der Regel aus einer Unmenge an Texten. Da es bei einer Anfrage an eine solche Datenbank unmöglich ist, den gesamten Bestand an Text-Dokumenten durchzusuchen, werden die Texte indexiert, d.h. dass aus den Texten jeweils eine Menge von aussagekräftigen Wörtern - eine so genannte Index-Menge - heraus gesucht wird, die den jeweiligen Text-Inhalt möglichst gut charakterisiert. Alle diese Mengen werden dann bezüglich deren Vereinigungsmenge normalisiert, um eine einheitliche Grundlage aller Texte zu haben. Stark vereinfacht ausgedrückt werden bei einer Anfrage an die Datenbank diese Index- Mengen mit einer aus der Anfrage generierten Index-Menge verglichen und bei einer bestimmten Übereinstimmung zwischen den Index-Mengen der zugehörige Text präsentiert. Offensichtlich hängt die Eignung eines Textes zur Informations-Befriedigung eines Benutzers der Datenbank davon ab, wie gut eine Index-Menge einen Text umschreibt. Aber auch

151 10.1. EINLEITUNG 137 die Art, nach welcher die Index-Menge der Anfrage mit den Index-Mengen der verschiedenen Text-Dokumente verglichen wird ist von großer Bedeutung, wie man in Tabelle 10.1 sehen kann. Dieses Beispiel beruht auf der Anfrage " Einfluss der Drogen-Einnahme auf das Gedächtnis und die kognitiven Fähigkeiten. Das Dokument soll sich jedoch nicht mit dem Alterungsprozess beschäftigen. Anmerkung: ".4." bedeutet, dass der Begriff auf der rechten Seite höchstens vier Wörter vom Begriff auf der linken Seite entfernt sein darf. Nummer Treffer Anfrage an die Datenbank Drogen Drogen (Körper-Kontrolle) Alterungsprozess Drogen (NICHT) Alterungsprozess #2 (SCHNITT) # Gedächtnis 7. 6 #5 (SCHNITT) (Drogen.4. Gedächtnis) kognitiv #5 (SCHNITT) (Drogen.4. kognitiv) #7 (VEREINIGUNG) # Nebenwirkung-Drogen (INDEX) #10 (SCHNITT) #11 Abbildung 10.1: Beispiel-Recherche zu obiger Anfrage an ein IR-System Die letzte (korrekte) Anfrage führte seltsamerweise zu keinem Ergebnis, obwohl mit Sicherheit davon ausgegangen werden kann, dass zu diesem Thema mehrere Werke existieren. Dieses Ergebnis ist im Übrigen typisch für die Suche in Literatur-Datenbanken. Die Frage ist nun, ob diese Schwierigkeiten typisch für das Information Retrieval sind, oder ob es Ansätze gibt, diese Schwierigkeiten zu lösen. In Kapitel 3 werden solche Ansätze beschrieben Ein Grund-Modell des IR Nachdem im vorigen Kapitel ein Beispiel von Information Retrieval aufgezeigt wurde, soll nun ein Grund-Modell des Information Retrieval dargestellt werden, auf dem alle IR-Systeme beruhen. Wohlgemerkt: hierbei handelt es sich nicht um das Modell des Information Retrieval, sondern nur um ein Modell des Information Retrieval. Das einzig wahre Grund-Modell des Information Retrieval gibt es nicht. Die Linke Seite in Abbildung 10.2 stellt den Vorgang bei der Eingabe der Daten in ein Retrieval-System dar. Diese sind z.b. die Text-Dokumente in Literatur-Datenbanken.

152 138 KAPITEL 10. INFORMATION RETRIEVAL Information Retrieval Analyse von Daten durch beruht auf Verfahren der Wissensrepräsentation gespeichert in Informationen beim Retrieval Transformationen auf liefert anhand von Internen Wissensstrukturen Abbildung 10.2: Ein Grund-Modell des Information Retrieval Die eingegebenen Daten werden analysiert und dann durch verschiedene Verfahren der Wissens-Repräsentation in das gespeicherte Wissen überführt. Ein Verfahren der Wissens- Repräsentation entspricht dabei z.b. der Indexierung von Texten in Literatur-Datenbanken. Beim Retrieval-Prozess wird die benötigte Information geliefert, indem die Anfrage auf die gespeicherten internen Wissensstrukturen durch verschiedene Verfahren transformiert wird. Dieses allgemeine Modell des Information Retrieval bildet die Basis für speziellere Modelle, wie z.b. das Dokument-Retrieval. Dabei werden die einzelnen Elemente des Grund- Modells durch geeignete Elemente des speziellen Retrievals ersetzt. Die Zusammenhänge zwischen diesen Elementen bleiben jedoch erhalten Information Retrieval bei Texten Wie bereits in der Einleitung erwähnt, sind Literatur-Datenbanken das Haupt-Aufgabenfeld des Information Retrieval. Die Frage ist nun, wie man die Literatur-Texte für eine spätere Suche geeignet aufbereitet. In der Einleitung wurde bereits angedeutet, dass nicht der gesamte Text als Grundlage für einen Vergleich zwischen Anfrage und gespeicherten Informationen dienen kann. Es wurde von Index-Mengen gesprochen, die aus dem Text anhand verschiedener Verfahren gebildet werden. Es ist offensichtlich, dass ein und derselbe Sachverhalt in verschiedenen Texten auf unterschiedlichste Weise dargestellt werden kann. Ein Beispiel hierfür wären alle Werke, die sich mit dem Verfall der kognitiven und mentalen Fähigkeiten durch Drogen-Missbrauch

153 10.2. INFORMATION RETRIEVAL BEI TEXTEN 139 befassen. Die Anfrage " Einfluss der Drogen-Einnahme auf das Gedächtnis und die kognitiven Fähigkeiten sollte genau diese Werke als Anfrage-Ergebnis liefern. Doch wie wird dies erreicht? Oder genauer: wie sollten die Index-Mengen möglichst aussehen, respektive gebildet werden, damit das korrekte Anfrage-Ergebnis geliefert wird? Um dieses Problem zu lösen, gibt es zwei verschiedene Ansätze. Der eine, die so genannte Freitextsuche befasst sich mit einer extrahierten Menge von Wörtern aus dem Text und bietet bestimmte Funktionen zur Verbesserung der Suche im Text an. Der andere Ansatz ist der so genannte semantische Ansatz. Hierbei wird versucht, anhand von Deskriptoren, die dem Text zugeordnet werden, eine semantische Repräsentation des Textes zu finden, die Syntax unabhängig ist. Syntax und Semantik solcher Deskriptionen sind in so genannten Dokumentationssprachen festgelegt. Der Haupt-Unterschied zur Freitextsuche ist der, dass versucht wird, eine neue, zusätzliche Repräsentation eines Textes zu erstellen. Im folgenden wird genauer auf die Freitextsuche eingegangen, da sie die heute vorherrschende Lösung zur Repräsentation von Text-Inhalten darstellt. Der semantische Ansatz und die damit verbundenen Dokumentationssprachen werden in [Fuh98, S.59ff] beschrieben Grundlegendes zur Freitextsuche Um die repräsentative Index-Menge von Wörtern eines Textes zu ermitteln, sind zunächst einige Vorarbeiten nötig. Im ersten Schritt wird der Text in einzelne Wörter zerlegt, wobei Leer- und Interpunktionszeichen als Worttrenner aufgefasst werden. Das Problem ist aber immer noch, dass der Text eine Unmenge von "nichts sagenden" Wörtern (z.b. "ist", "hat", "kann" etc.) enthält. Diese Redundanz wird eliminiert mit dem Ergebnis, dass der Text-Umfang auf ca. die Hälfte abgenommen hat. Dadurch wird natürlich die Effizienz beim Suchvorgang weiter gesteigert. Zu guter letzt wird eine Satzende-Erkennung durchgeführt, die jedoch nur approximativ erfolgen kann, da in fast allen Texten z.b. der Punkt auch als Abkürzungszeichen genutzt wird. Um nun die Suche in dieser indizierten Wort-Menge zu verbessern werden zwei unterschiedliche Ansätze verfolgt. Zum einen der Informatische Ansatz, der das Text-Retrieval als Zeichenkettensuche auffasst, zum anderen der Computerlinguistische Ansatz. Der Informatische Ansatz stellt verschiedene Funktionen auf Zeichenkettenebene zur Verbesserung der Trefferquote beim Retrieval zur Verfügung, während der Computerlinguistische Ansatz anhand von verschiedenen Verfahren eine Normalisierung von Wortformen anstrebt. Die Suche bezieht sich dann auch nicht mehr nur auf Zeichenketten wie beim Informatischen Ansatz, sondern auf Wörter, bzw. deren Wortstämme Probleme bei der Freitextsuche Nach einer notwendigen Vorverarbeitung (s.o.) des Textes wurde eine Menge von Wörtern geschaffen, die den Text mehr oder weniger gut repräsentiert. Bei der Freitextsuche auf dieser Menge ergeben sich nun folgende Probleme, die es zu lösen gilt:

154 140 KAPITEL 10. INFORMATION RETRIEVAL Homographen: Homographen sind verschieden gesprochene Wörter mit gleicher Schreibweise, z.b. Tenor: Sänger / Ausdrucksweise Polyseme: Polyseme sind Wörter mit mehreren Bedeutungen, z.b. Bank: Sitzgelegenheit / Geldinstitut (das berühmte Teekesselchen...) Flexionsformen: Flexionsformen sind Wörter, die durch Konjunktion oder Deklination entstehen, z.b. Haus - (des) Hauses - Häuser Derivationsformen: Derivationsformen sind verschiedene Wörter zu einem Wortstamm, z.b. Formatierung - Format - formatieren Komposita: Komposita sind mehrgliedrige Ausdrücke, z.b. Bundeskanzler-Wahl - Wahl des Bundeskanzlers Anzumerken ist, dass der Erfolg einer Anfrage auch stark von der Wortwahl des Anfragenden abhängt. Der Benutzer eines Information Retrieval Systems sollte sich seine Anfrage und die darin verwendeten Wörter immer gut überlegen, um möglichst schnell zu einem zufrieden stellenden Suchergebnis zu kommen Informatischer Ansatz Wie bereits im vorigen Kapitel angerissen, stellt der Informatische Ansatz verschiedene Funktionen auf Zeichenkettenebene zur Verfügung, um das Retrieval-Ergebnis bei einer Suchanfrage zu erhöhen. Die Suchbasis beim Informatischen Ansatz basiert auf einer indizierten Menge von Wörtern, der so genannten Index-Menge, die bei der Vorverarbeitung der Freitextsuche (s.o.) erzeugt wurden. Die Suche beim Informatischen Ansatz bezieht sich zum einen auf die Suche einzelner Wörter, zum anderen auf die Suche nach einzelnen Folgen von Wörtern. Für diese Suche werden verschiedene Operationen angeboten, um beim Retrieval eine höhere Trefferquote zu erreichen. Aufgrund der relativ einfachen Implementierbarkeit von solchen Algorithmen mit dem Computer ist der Informatische Ansatz die Grundlage fast aller kommerziell angebotenen IR-Systeme. Für die Suche von einzelnen Wörtern in der Index-Menge werden Trunkierungs- und Maskierungsoperationen angeboten. Diese Operationen basieren im Allgemeinen auf so genannten "Wildcards", oder "Platzhalter", wie sie beispielsweise auch ordentliche Betriebssysteme bei der Datei-Verwaltung bieten. Diese Operationen bieten die Möglichkeit, einzelne Flexions- und Derivationsformen von Wörtern zusammenzuführen und das Problem der Flexion, beziehungsweise Derivation zu reduzieren. Der Unterschied zwischen Trunkierung und Maskierung besteht in der Anwendung der Platzhalter. Werden sie nur am Wortanfang, oder -ende angewandt, spricht man von Trunkierung, andernfalls spricht man von Maskierung. Nachteil dieser Operationen ist, dass sie auch Wörter akzeptieren, die offensichtlich nicht gewünscht sind. Zu lesen sind die Beispiele wie folgt. Auf der linken Seite findet sich das trunkierte, bzw. maskierte Wort, auf der rechten Seite die möglichen Wörter, für die ein positiver "Match" auftreten würde.

155 10.2. INFORMATION RETRIEVAL BEI TEXTEN 141 ffl Beispiele für Trunkierung: schreib#: schreiben, schreibt, schreibst, schreibe schreib$$: schreiben, schreibst #schreiben: schreiben, beschreiben, anschreiben, verschreiben $$schreiben: beschreiben, anschreiben ffl Beispiele für Maskierung: schr$$b#: schreiben, schrieb / schrauben h$$s#: Haus, Häuser / Hanse, hausen, hassen Legende: $ steht für ein Symbol, # für beliebig viele. Wie man sieht, treten bei bestimmten Konstellationen von Platzhaltern und verwendetem Wort bei der Maskierung Fehl-Übereinstimmungen auf. Diese kommen dadurch zustande, dass offensichtlich "zu viel" im Wort maskiert wurde und somit auch andere Wörter gefunden werden können, die offensichtlich mit dem gesuchten Wort nichts gemein haben. Bei der Suche nach mehrgliedrigen Ausdrücken stehen Kontext-Operationen zur Verfügung, die ebenfalls das Retrieval-Ergebnis erhöhen können. Hierbei wird nun nicht mehr einfach nach Übereinstimmung zwischen einzelnen Wörtern gesucht, sondern man besitzt die Möglichkeit, nach Wörtern zu suchen, die in einem gewissen Kontext zueinander stehen. So könnte der Suchausdruck "information retrieval" im Suchtext auch in der Form "information storage and retrieval" vorhanden sein. Würde man jetzt nach genau diesem Suchausdruck suchen, würde man in obigem Suchtext nicht fündig werden. Es sei denn, man benutzt boolesche Verknüpfungen zwischen den Suchwörtern. Dann sucht man jedoch nach "information" und "retrieval" und bekommt unter Umständen eine sehr hohe Anzahl von Texten geliefert, in denen die beiden Begriffe zwar vorkommen, die Texte an sich aber nichts mit Information Retrieval zu tun haben. Um einen Ausweg aus diesem Dilemma zu finden, wurden Operationen geschaffen, die auf Kontext-Ebene arbeiten. Häufige Operationen sind: ffl genauer Wort-Abstand ($) retrieval $ information: retrieval of information, retrieval with information ffl maximaler Wort-Abstand (#) text ## retrieval: text retrieval, text and fact retrieval ffl Wort-Reihenfolge (,): ffl gleicher Satz (.):

156 142 KAPITEL 10. INFORMATION RETRIEVAL Computerlinguistischer Ansatz Der zweite Ansatz zur Bewältigung der Probleme bei der Freitextsuche in Text-Dokumenten ist der Computerlinguistische Ansatz, der in diesem Abschnitt jedoch nur kurz beschrieben werden soll. Eine genauere Beschreibung des Computerlinguistischen Ansatzes findet man in[fuh98, S.52ff]. Im Gegensatz zum Informatischen Ansatz, bei dem die Probleme der Flexion und Derivation durch simple Muster-Vergleiche zu lösen versucht wird,versucht der Computerlinguistische Ansatz, die verschiedenen Derivations- und Flexionsformen auf den Wortstamm zurückzuführen. Dabei werden verschiedene Ansätze verfolgt. ffl graphematische Verfahren basieren auf der Analyse von Buchstabenfolgen, um die verschieden Derivations- und Flexionsformen eines Wortes zusammenzuführen. ffl lexikalische Verfahren basieren auf Wörterbüchern, in denen der Wortstamm und die verschiedenen Vorkommen dieses Wortstamms verzeichnet sind. ffl syntaktische Verfahren dienen dazu, mehrgliedrige Ausdrücke zu identifizieren. Es ist jedoch zu beachten, dass diese Ansätze - wie die des Informatischen Ansatzes - nicht perfekt sind und der Erfolg der Verfahren stark von der Sprache abhängt, in der die Texte verfasst sind. So ist z.b das graphematische Verfahren für englische Texte erfolgreicher als für deutsche. Dies liegt daran, dass die englische Sprache im Gegensatz zur deutschen nicht so stark flektiert ist. Folglich bieten sich bessere und genauere Möglichkeiten, die verschieden Flexionsformen eines Wortes auf den Stamm zu reduzieren IR-Ansätze Um das grundlegende Ziel des Information Retrieval - die Wiedererlangung von gespeicherten Informationen in effizienter und effektiver Art und Weise - zu erreichen, wurden im laufe der Jahre viele verschiedene Verfahren entwickelt, um die Anzahl und Qualität der nach einer Anfrage gefundenen Ergebnisse zu erhöhen. Dabei werden zwei vom Ansatz her ganz unterschiedliche Richtungen eingeschlagen: zum einen der nicht-probabilistische Ansatz, zum anderen der probabilistische Ansatz, welcher jedoch noch sehr in den Anfängen steckt und bisher größtenteils auf Theorien-Bildung basiert. Der nicht-probabilistische Ansatz hingegen ist der heute am häufigsten verwendete Weg, um ein IR-System zu entwerfen. Der grundlegende Unterschied zwischen den beiden Richtungen und die verschiedenen daraus abgeleiteten Ansätze werden in den Kapiteln 3.2 und 3.3 dargestellt. Zunächst jedoch sollen einige Grundlagen vermittelt werden, um die Qualität und Quantität der Ergebnisse nach einer Anfrage an ein IR-System zu bewerten. Aus diesen unerlässlichen Kenngrößen heraus lässt sich dann eine Bewertung von IR-Systemen ableiten.

157 10.3. IR-ANSATZE Bewertung von Anfrage-Ergebnissen Um bei der Untersuchung von IR-Systemen eine einheitliche Grundlage zu haben, müssen Kenngrößen eingeführt werden, die die Effizienz und Effektivität von IR-Systemen darstellen. Hierbei ist zu beachten, dass diese Kenngrößen in der Regel durch Evaluierung ermittelt werden, da andere, rein auf Theorie basierende Bewertungsverfahren zu wenig Aussagekraft besitzen. Dies liegt vor allem daran, dass das Gebiet des Information Retrieval zu komplex ist, um es in ein Theorien-Gebilde zu pressen. Effizienz im Zusammenhang mit IR-Systemen bedeutet, dass ein möglichst sparsamer Umgang mit den System-Ressourcen eines IR-Systems angestrebt wird. Zu diesen System- Ressourcen zählen u.a. die CPU-Zeit, die eine IR-Anfrage erfordert, der Speicher-Verbrauch eines IR-Systems, die Anzahl der Datei-Operationen, die zur Bearbeitung einer Anfrage nötig sind etc. Alles in allem ist die Effizienz eines IR-Systems unmittelbar messbar. Die Effektivität eines IR-Systems beschreibt das Verhältnis zwischen Kosten und Nutzen eines IR-Systems. Kosten müssen hierbei im Sinne von Aufwendungen des Nutzers verstanden werden, die nötig sind, um ein zufrieden stellendes Anfrage-Ergebnis zu erhalten. Der Nutzen beschreibt hingegen die Qualität des Anfrage-Ergebnisses für den Nutzer des IR-Systems. Um diese Qualität messen zu können führt man den Begriff der Relevanz ein. Die Relevanz setzt die Antwort eines IR-Systems in Beziehung zur gestellten Anfrage, wodurch sich feststellen lässt, wie weit eine Antwort zu einer Anfrage passt. Hierbei ist zu beachten, dass eine Antwort eines IR-Systems stets Mengen von Antworten sind und dass die Relevanz eines Anfrage-Ergebnisses nur von der Anfrage selbst abhängt Recall, Precision, Fallout Um Aussagen darüber treffen zu können, inwieweit ein Anfrage-Ergebnis für den Nutzer eines IR-Systems von Nutzen ist, werden einige Kenngrößen eingeführt, die bei der Bewertung von IR-Systemen unerlässlich sind. Wie im vorigen Kapitel beschrieben, beruht der Begriff der Relevanz auf der Annahme, dass das Anfrage-Ergebnis eines IR-Systems stets eine Menge von Antworten ist, die eine Teilmenge aller möglichen Antworten darstellt. Die für den Nutzer relevanten Antworten sind wiederum eine Teilmenge dieser Mengen, so dass sich folgendes Schaubild aus Abbildung 10.3 ergibt. Die Kenngrößen Recall, Precision und Fallout ergeben sich nun aus Verhältnissen der einzelnen Teilmengen zueinander. Dabei gibt das Recall das Verhältnis zwischen den gefundenen relevanten Antworten und allen relevanten Antworten an. Recall : r = j GEF REL j j REL j Hierbei stellt sich das Problem, dass es schwer feststellbar ist, wie viele relevante Antworten nicht gefunden wurden, da unbekannt ist, wie viele relevante Antworten überhaupt existieren. Um dieses Problem zu lösen, werden heuristische Mittel angewandt, um die Anzahl der verbleibenden relevanten Antworten ungefähr zu bestimmen. Die Precision beschreibt, wie präzise ein Anfrage-Ergebnis war. Dabei wird das Verhältnis der gefundenen relevanten Antworten zu allen gefunden Antworten gebildet. P recision : p = j GEF REL j j GEF j

158 144 KAPITEL 10. INFORMATION RETRIEVAL ALL GEF REL Abbildung 10.3: Teilmengen eines Anfrage-Ergebnisses Das Fallout schließlich beschreibt das Verhältnis von gefundenen irrelevanten Antworten zu allen irrelevanten Antworten eines IR-Systems. F allout : f = j GEF REL j j ALL REL j Je höher die Werte von Recall und Precision sind, desto besser ist die Qualität des Anfrage-Ergebnisses. Jedoch wird der Maximalwert von 1, der ja eine hundertprozentige Trefferquote darstellt, in der Regel nie erreicht Der nicht-probabilistische Ansatz Der nicht-probabilistische Ansatz ist der heute am meisten verfolgte Ansatz, um IR- Systeme zu entwerfen. Hierbei wird - grob gesagt - auf den vorhandenen Daten gearbeitet, ohne aus diesen Daten neue Daten zwecks besserer Retrieval-Qualität zu generieren. Das Retrieval-Ergebnis hängt demzufolge in großem Maße von der Repräsentation der gespeicherten Daten ab. Die einfachste Repräsentation ist eine Auswahl von Stich-Wörtern, die ein Objekt beschreiben, ohne eine Gewichtung dieser Wörter vorzunehmen. Dieses Verfahren wird z.b. im Booleschen Retrieval verwendet, dem einfachsten Retrieval-Verfahren. Leider besitzt dieses naive Verfahren zahlreiche Unzulänglichkeiten, wodurch sich im Laufe der Zeit auf Basis des Booleschen Retrieval verschiedene Varianten herausbildeten, die alle versuchen, die Mängel des Booleschen Retrieval durch geeignete Erweiterungen und Modifikationen zu beheben. Alle Ansätze basieren jedoch auf ein und demselben Grund- Modell, welches in Abbildung 10.4 dargestellt ist. Das Grund-Modell muss wie folgt verstanden werden: Q und D sind die Mengen der Anfragen an das Information Retrieval System, bzw. die Menge der Objekte in der Datenbasis. Zwischen den Anfragen und den Objekten der Datenbasis besteht eine Relevanz- Beziehung. Die möglichen Relevanz-Urteile sind in der Menge R enthalten. Q und D sind Frage, bzw. Objekt-Repräsentationen, die mittels der Funktionen ff Q bzw. ff D aus den Mengen der Anfragen und Objekten gewonnen werden. Diese Repräsentationen können

159 10.3. IR-ANSATZE 145 R α Q β Q Q Q Q ρ rel. Urteile αd βd D D D Abbildung 10.4: Das Grund-Modell des nicht-probabilistischen Ansatzes D D R z.b. Terme sein, die das Objekt oder die Anfrage charakterisieren. Näheres findet sich in Kapitel 2. Um nun ein Retrieval durchführen zu können, werden die Frage- und Objekt- Repräsentationen in Frage- bzw. Objekt-Beschreibungen Q D bzw. D D überführt. Dies vollziehen die Funktionen fi Q bzw. fi D. Beim Retrieval wird nun mittels der Retrieval- Funktion ρ eine reelle Zahl errechnet, die sich aus einem Vergleich zwischen einer Frage- Beschreibung und einer Objekt-Beschreibung ergibt. Diese reelle Zahl wird dann letztendlich dem jeweiligen Objekt zugeordnet und kann vom Information Retrieval System weiter verarbeitet werden. Näheres zu Abbildung 10.4 findet man in [Fuh98, S.83] Das Boolesche Retrieval Das Boolesche Retrieval ist wie bereits erwähnt das älteste Retrieval- Modell, das existiert. Dieses Retrieval-Modell ist in sich recht einfach gehalten, was aufgrund der damaligen Hardware-Verhältnisse erforderlich war. Erstaunlicherweise ist das Boolesche Retrieval heute immer noch der am meisten verfolgte Ansatz beim Information Retrieval im kommerziellen Bereich, was wahrscheinlich ökonomische Gründe hat. Das Grundprinzip beim Booleschen Retrieval ist ein einfacher Vergleich zwischen den Dokument-Beschreibungen und der Frage-Beschreibung. Die Dokument-Beschreibung stellt eine ungewichtete Indexierung der Datenbasis dar, während die Frage-Beschreibungen boolesche Ausdrücke sind, welche aus den Elementen der Anfrage gebildet wird. Dadurch, dass das gesamte System binär arbeitet, kann das Boolesche Retrieval lediglich feststellen, ob ein Objekt der Datenbasis zu einer Anfrage passt, oder nicht. Indexierungen oder Rangfolgen der gefundenen Objekte gibt es nicht. Dies ist auch der größte Nachteil des Booleschen Retrieval. Weitere Nachteile sind unter anderem die Schwierigkeit, eine Anfrage zu erschaffen, die auch wirklich die für die Bedürfnis-Befriedigung relevanten Dokumente findet, sowie das Problem der Beherrschbarkeit der Mächtigkeit der Antwort-Menge. Letzteres kommt dadurch zustande, dass bereits die Hinzunahme eines einzigen zusätzlichen Begriffs in der Anfrage zu total unterschiedlichen Ergebnis in der Antwort-Menge führen kann. Andersherum ist dies natürlich genauso möglich. Von einer sukzessiven Verfeinerung der Anfrage kann somit keine Rede sein Das Ranking-Verfahren Eine Verfeinerung des groben Booleschen Retrievals ist das Ranking-Verfahren. Die Verfeinerung besteht in der Idee, den Elementen der Anfrage-Menge Gewichte - auch negative - zuzuordnen. Die Frage-Beschreibung ist nun also nicht mehr ein einfacher boolescher

160 146 KAPITEL 10. INFORMATION RETRIEVAL Ausdruck. Die Dokument- Beschreibungen sind jedoch weiterhin ungewichtet. Dadurch sind nun bei der Retrieval-Funktion auch andere Ergebnisse möglich als 0 oder 1. Je mehr ein Objekt der Anfrage entspricht, desto höhere Werte durch die Retrieval- Funktion werden auch erreicht. Die verschiedenen Werte, die den Objekten der Antwort-Menge zugeordnet werden können, ermöglichen nun eine Rangfolge derselben (daher auch der Name "Ranking-Verfahren"). Um das Verfahren etwas zu verdeutlichen, soll ein einfaches Beispiel gebracht werden, wie das Ranking-Verfahren funktioniert. In Kapitel 1 wurde das Problem der Anfrage " Einfluss der Drogen-Einnahme auf das Gehirn und die kognitiven Fähigkeiten dargestellt. Die Anfrage-Ergebnisse sollten sich jedoch nicht mit dem Altern beschäftigen. Als markante Suchwörter benutzen wir "Nebenwirkung(1)", "Drogen(1)", "Gedächtnis(1)", "kognitiv(1)", "Alterungsprozess(-1)". Die Gewichtungen sind in Klammern angegeben. Für jedes Objekt (hier: d 1, d 2, d 3, d 4 ) der Datenbasis wird nun ein Wert der Retrieval-Funktion ermittelt. Dieser Wert stellt das Retrieval-Gewicht der Objekte dar. Die Retrieval-Funktion ist in unserem Beispiel die Summe der Produkte aus den Gewichtungen der Suchwörter und dem Auftreten der Wörter in den Objekten. Die Rangfolge der gefunden Objekte wäre demnach d 3, d 1, d 4, d 2. Das Beispiel ist nochmals in Abbildung 10.5 dargestellt. Frage-Term Gewicht d 1 d 2 d 3 d 4 Nebenwirkung 1 x x x x Drogen 1 x x x x Gedächtnis 1 x x kognitiv 1 x x x Alterungsprozess -1 x Retrieval-Gewicht Abbildung 10.5: Beispiel des Ranking-Verfahrens Das Fuzzy-Retrieval Ein weiterer Ansatz, die Unzulänglichkeiten des Booleschen Retrievals zu beseitigen ist das Fuzzy-Retrieval, welches - wie der Name schon vermuten lässt - auf der Theorie der Fuzzy-Logik basiert. Anders als beim Booleschen Retrieval, sind beim Fuzzy Retrieval die Indexe in den Dokument- Beschreibungen gewichtet, d.h. dass ihnen beliebige Werte zwischen 0 und 1 zugeordnet werden. Je höher ein Gewicht ist, desto öfter tritt der Index-Term in einem Objekt auf und umgekehrt. Damit ähnelt das Fuzzy Retrieval stark dem Ranking-Verfahren, welches jedoch die Frage-Beschreibungen gewichtet und die Dokument-Beschreibungen ungewichtet lässt. Durch die Verwendung von Werten im Intervall [0,1] bei den Indexen in Kombination mit dem booleschen Ausdruck der Frage-Beschreibung liefert die Retrieval-Funktion beim Fuzzy-Retrieval von 0, bzw. 1 verschiedene Werte. Diese werden dann weiter genutzt, um

161 10.3. IR-ANSATZE 147 eine Rangfolge der gefundenen Objekte zu erstellen, also die Objekte, die wohl am ehesten der Anfrage entsprechen in einer Liste weiter nach vorn zu setzen Das Vektorraummodell In den vorherigen Kapiteln wurden verschiedene Modelle vorgestellt, die alle versuchten, die Qualität des Retrieval-Ergebnisses einer Anfrage an ein IR-System zu verbessern. Basis dieser Modelle war immer das Boolesche Retrieval, welches durch verschiedene Ansätze in einigen Punkten verbessert wurde. Die Ansätze wiederum postulierten eine Gewichtung von den Termen der Frage-Beschreibung, bzw. der Dokument-Beschreibungen, jedoch niemals beides gleichzeitig. Das Vektorraummodell versucht nun, weitere Nachteile des Booleschen Retrievals zu kompensieren. Im Gegensatz zum Ranking-Verfahren und Fuzzy- Retrieval werden beim Vektorraummodell sowohl die Terme der Dokumenten- als auch der Frage-Beschreibung gewichtet. Die Grundidee des Vektorraummodells ist die, dass man die Terme der Datenbasis als Basis eines Vektor-Raums darstellt. Jedes Objekt der Datenbasis wird nun als Punkt in diesem Vektor-Raum verstanden, wobei die Komponenten des Vektors praktisch die Gewichtung der einzelnen Terme der Datenbasis sind. Wird nun eine Frage an das IR-System gestellt, wird auch diese als Vektor verstanden und dieser dann mit den Vektoren der Objekte der Datenbasis verglichen. Dabei wird ein metrisches System verwendet. Ein Frage-Vektor muss nicht haargenau zu einem Objekt- Vektor passen, sondern nur ähnlich diesem sein. Die Retrieval-Funktion liefert dann quasi die "Ähnlichkeit" eines Objekt-Vektors zu einem Frage-Vektor. Eine Ähnlichkeit zwischen Vektoren wird über verschiedene Vektor-Ähnlichkeitsmaße berechnet, z.b. das Cosinus- Maß, wobei jedoch meistens mit dem Skalarprodukt gearbeitet wird. Die Objekte, die dem Frage-Vektor am ähnlichsten sind, stehen in der Rangordnung der gefunden Objekte ganz oben, diejenigen, die dem Frage-Vektor sehr unähnlich sind ganz unten. Ein Beispiel eines Vektorraummodells, wo das Skalarprodukt als Ähnlichkeitsmaß zur Anwendung kommt, findet sich in Abbildung Die Spalten d 1, d 2, d 3, d 4 sind die Objekt-Vektoren bezüglich der Basis-Terme Nebenwirkung, Drogen, Gedächtnis, kognitiv, Alterungsprozess). Basis-Vektoren Frage-Vektor d 1 d 2 d 3 d 4 Nebenwirkung Drogen Gedächtnis kognitiv Alterungsprozess -2 1 Retrieval-Gewicht Abbildung 10.6: Beispiel des Vektorraummodells

162 148 KAPITEL 10. INFORMATION RETRIEVAL Ein besonderer Vorteil des Vektorraummodells gegenüber dem Ranking-Verfahren oder dem Fuzzy-Retrieval ist die Möglichkeit, das Retrieval-Ergebnis automatisch weiter zu verbessern, was als Relevance Feedback bezeichnet wird. Relevance Feedback versucht, durch Veränderungen des Frage-Vektors die Frage selbst wieder in den Raum der relevanten Objekte zu führen, also die Anzahl der gefundenen irrelevanten Objekte weiter einzugrenzen. Um dies zu erreichen werden Angaben über die Relevanz, bzw. Nicht-Relevanz einiger Objekte verwendet. Jedoch wird ein neuer Frage-Vektor nicht generiert, ohne den ursprünglichen Frage-Vektor zu verwenden, da ja immer noch relevante Objekte existieren können, die noch gar nicht erfasst wurden. Ohne eine Berücksichtigung des ursprünglichen Frage-Vektors könnte sich der über Relevance Feedback generierte, neue Frage-Vektor von diesen nicht gefundenen, relevanten Objekten weiter entfernen, wodurch das Retrieval- Ergebnis beeinträchtigt würde. Durch die Verwendung des Relevance Feedback wird i.a. das Retrieval-Ergebnis jedoch weiter verbessert Das Dokumenten-Clustering Das Dokumenten-Clustering unterscheidet sich gänzlich von den oben vorgestellten Verfahren, da dieses nicht explizit auf eine Fragestellung angewiesen ist. Eine Suche nach relevanten Objekten in der Datenbasis erfolgt nicht durch einen ständigen Vergleich der Frage mit den Objekten der Datenbasis. Vielmehr werden die Ähnlichkeiten zwischen den verschiedenen Objekten der Datenbasis verwendet, um von einem relevanten Objekt zu weiteren vermutlich relevanten Objekten zu kommen. Ähnliche Objekte werden vorher bestimmt und zu so genannten Clustern zusammengefasst. Um die Ähnlichkeit zwischen den Objekten zu ermitteln, wird zunächst ein Ähnlichkeitsmaß festgelegt, auf dessen Basis eine Ähnlichkeits-Matrix mit allen möglichen Ähnlichkeitspaaren erstellt wird. Aus dieser Matrix werden dann mit verschiedenen Algorithmen die Cluster gebildet, die dann die zueinander ähnlichen Objekte beinhalten. Aus Effizienzgründen werden dann die Objekte eines Clusters gemeinsam abgespeichert, um möglichst wenig IO-Operationen beim Retrieval zu benötigen. Eine Suche beim Dokumenten-Clustering sieht schließlich so aus, dass zunächst ein Anfangs- Objekt gefunden werden muss, welches praktisch als Anker für die Bestimmung des bzw. der passenden Cluster dient. Dieses Objekt wird üblicherweise über das Vektorraummodell gesucht Der probabilistische Ansatz Das große Problem des Information Retrieval im Gegensatz zu Standard-Datenbanken ist einerseits die Schwierigkeit auf Seiten des IR-Systems zu entscheiden, welche Objekte der Wissens-Datenbank denn nun das Informations-Bedürfnis des Benutzers befriedigen. Andererseits gibt es die Schwierigkeit auf Seiten des Benutzers die Fragestellung zu konstruieren, die auch wirklich zur Bedürfnis-Befriedigung geeignet ist. Die nicht-probabilistischen Ansätze, wie sie im vorherigen Kapitel beschrieben wurden, versuchen diese Probleme zu lösen, wenngleich sie auch zahlreiche Unzulänglichkeiten aufweisen. Um die oben aufgeführten Schwierigkeiten besser zu überwinden, wurde der probabilistische Ansatz entwickelt. Grundlage dieses Ansatzes ist es, mit Hilfe von Wahrscheinlichkeitsaussagen zu ermitteln, welche Objekte der Wissens-Datenbank ein bestimmtes

163 10.3. IR-ANSATZE 149 Informations-Bedürfnis möglicherweise befriedigen. Dazu werden den Objekten der Datenbank Wahrscheinlichkeiten zugewiesen, inwieweit diese ein bestimmtes Informations- Bedürfnis befriedigen. Generell gibt es zwei verschiedene Ansätze beim probabilistischen Ansatz. Der erste, so genannte klassische Ansatz verlangt vom Benutzer, Relevanz-Urteile zu Objekten des Anfrage-Ergebnisses anzugeben, inwieweit diese sein Informations-Bedürfnis befriedigen. Aus diesen Angaben berechnet das IR-System dann Wahrscheinlichkeiten, wie weit andere Objekte der Wissens-Datenbank das Informations-Bedürfnis des Benutzers zu befriedigen. Der zweite, so genannte neue Ansatz verzichtet auf die subjektiven Urteile des Benutzers und zieht seine Schlussfolgerungen der Wahrscheinlichkeitszuordnungen automatisch. Dieser Ansatz wurde zuerst von van Rijsbergen formuliert, einem der Vordenker des Information Retrieval. Der probabilistische Ansatz ist zwar sehr viel versprechend, aber leider noch nicht über das Entwicklungsstadium hinausgekommen. Demzufolge spielt dieser Ansatz beim heutigen Information Retrieval quasi keine Rolle, obgleich er ein gewaltiges Potential bietet Die Grundidee des probabilistischen Ansatzes Die Grundidee des probabilistischen Ansatzes ist die Entscheidung zu treffen, mit welcher Wahrscheinlichkeit ein Objekt der Wissens-Datenbank ein Informations-Bedürfnis befriedigt. Um dies zu erreichen, wird wieder mit Index-Mengen gearbeitet (Vgl. Kapitel 2), deren Terme i.a. Wortstämme sind. Es ist offensichtlich, dass diese Terme in den verschiedenen Objekten der Datenbank in verschiedenen Konstellationen auftreten können. Man betrachtet also die Verteilung der Terme in den Objekten. Die Grundannahme, die nun gemacht wird, ist die Einflussnahme der Verteilung dieser Terme auf die Relevanz eines Objektes zu einem bestimmten Informations-Bedürfnis. Im Klartext bedeutet dies, dass z.b. die charakteristischen Merkmale (die extrahierten Terme) von Text-Dokumenten, die sich mit verschiedenen Themen befassen, je nach Thema in bestimmten Konstellationen auftreten. Diese Annahme wurde bereits experimentell bestätigt [vrj73]. Daraus resultiert die Idee, dass nun nicht mehr direkt mit dem Auftreten der Terme in den Objekten der Datenbank gearbeitet wird, wie es beim nicht-probabilistischen Modell der Fall ist, sondern es wird mit der Verteilung dieser Terme in den Objekten gearbeitet. Falls mehrere Objekte die gleiche Verteilung von Termen aufweisen, haben sie wahrscheinlich auch die gleiche Relevanz zur Befriedigung eines bestimmten Informations-Bedürfnisses und umgekehrt. Eine Anfrage an das IR-System wird als eine Auswahl von Termen der Menge aller Terme der Index-Menge aufgefasst, jedoch gibt es auch andere Formen die Anfrage zu generalisieren. Über verschiedene Annahmen wird nun versucht, ein "retrieval status value" (RSV) zu berechnen, der die Wahrscheinlichkeit ausdrückt, inwieweit ein Dokument zu einer Anfrage passt. Je kleiner der RSV eines Dokument-Anfragepaares ist, desto unwahrscheinlicher ist es, dass dieses Dokument das in einer Anfrage ausgedrückte Informations-Bedürfnis deckt. Der RSV geht demnach direkt in eine Rangordnung der Objekte ein. Näheres findet sich in [Fuh98, S.99ff].

164 150 KAPITEL 10. INFORMATION RETRIEVAL 10.4 Bewertung gegenwärtiger Systeme Im vorherigen Kapitel wurden zwei grundsätzlich verschiedene Ansätze für die Realisierung von Information Retrieval Systemen vorgestellt. Der nicht-probabilistische Ansatz beruht auf der Idee, mit Hilfe von verschiedenen Verfahren der Wissens-Repräsentation ein immer besser werdendes Retrieval-Ergebnis zu erhalten. Dem gegenüber steht der probabilistische Ansatz, der mit Hilfe der Wahrscheinlichkeitstheorie die Zuordnungen zwischen der Anfrage und den Objekten der Datenbasis herstellt. Es stellt sich nun die Frage, welcher von den beiden Ansätzen denn nun der "bessere" ist, d.h. welcher von beiden die besseren Retrieval-Ergebnisse liefert. Dies ist beileibe nicht einfach zu bestimmen, da der probabilistische Ansatz de facto nur in der Theorie existiert und aktuell auch keine Systeme bestehen, die auf dessen Idee basieren. Es ist also unmöglich, die beiden Systeme in der Praxis zu vergleichen, da für den probabilistischen Ansatz keine praktischen Evaluationsergebnisse existieren. Man könnte nun auf den Gedanken kommen, die Systeme in eine Theorien-Gebilde zu pressen, was jedoch wenig Sinn macht, da, wie bereits erwähnt, das Gebiet des Information Retrieval viel zu komplex ist, um so vernünftige Aussagen zu erhalten. Daher kann eine Bewertung von Information Retrieval Systemen nur für die gegenwärtigen Systeme erfolgen, die alle samt zur Kategorie des nicht-probabilistischen Ansatzes gehören Bewertung des Booleschen Retrieval Der Vorreiter aller nicht-probabilistischen Ansätze ist das Boolesche Retrieval, welches damit natürlich auch das älteste aller Information Retrieval Systeme ist. Durch die Einfachheit dieses Verfahrens in den Dokument- und Frage-Beschreibungen und die daraus resultierende simple Retrieval-Funktion besitzt dieses Verfahren auch die größten Mankos aller Systeme. Das Boolesche Retrieval besitzt weder Möglichkeiten, die Antwort-Menge von Objekten zu ordnen, noch Möglichkeiten, diese in irgendeiner Weise zu kontrollieren. Zudem ist die Frage-Formulierung im Booleschen Retrieval sehr umständlich und kann ungeübte Benutzer rasch überfordern Bewertung des Ranking-Verfahrens Das Ranking-Verfahren stellt zwar durch die Gewichtung der Frage-Terme eine Ordnung der Antwort-Menge bereit. Jedoch bleiben alle anderen Nachteile des Booleschen Retrievals erhalten, weshalb auch das Ranking-Verfahren als "gutes" Retrievalverfahren ausscheidet. Umso erstaunlicher ist allerdings, dass heute fast alle kommerziellen Systeme auf dem Boolesche Retrieval, beziehungsweise dem Ranking-Verfahren basieren. Dies liegt wohl an ökonomischen Gründen, da diese Systeme im Verhältnis zu anderen recht einfach zu realisieren sind. Der heutige Stand der Technik müsste als limitierender Faktor eigentlich ausfallen.

165 10.5. AUSBLICK AUF DIE ZUKUNFT Bewertung des Fuzzy-Retrieval Das Fuzzy-Retrieval bringt den Vorteil mit sich, dass durch die gewichteten Indexierungen der Objekte der Datenbasis eine Rangordnung der gefundenen Objekte vorgenommen werden kann. Allgemein lässt sich sagen, dass die Vor- und Nachteile des Fuzzy-Retrieval sich nicht von denen des Ranking-Verfahrens unterscheiden. Dies leuchtet ein, wenn man sich sich die zugrunde liegenden Ideen hinter diesen beiden Retrievalverfahren anschaut. Leider ist damit auch das Fuzzy-Retrieval kein guter Kandidat für ein gutes Retrievalverfahren. Allerdings gibt es eine Erweiterung des Fuzzy- Retrieval, in dem auch eine gewichtete Indexierung der Frage-Formulierung zugelassen wird. Näheres findet man in [Boo85]. Jedoch wurde diese Erweiterung bis dato noch nicht evaluiert, und damit lassen sich leider keine weiteren Beobachtungen zu dieser Erweiterung anstellen Bewertung des Vektorraummodells Das Vektorraummodell wird mittlerweile seit 1961 entwickelt. Der Urheber dieses Verfahrens ist Gerard Salton, einer der Pioniere des Information Retrieval. Eine Überarbeitung erfuhr das Modell in den achtziger Jahren von Wong und Raghavan [RW86]. Das Potential dieses Verfahrens ist enorm. Durch die einfache Frage-Formulierung dieses Systems ist es auch ungeübten Benutzern möglich, schnell zu zufrieden stellenden Ergebnissen zu kommen. Obendrein ist die Retrieval-Qualitätbeim Vektorraummodell i.a. sehr gut, ebenso die Erweiterbarkeit eines vorhandenen Daten-Bestandes. Allerdings wird bei der Bestimmung der Objektgewichte, also der Position eines Objektes im Vektor-Raum viel Heuristik verwendet, was eine Änderung von Gewichten eines Objektes enorm erschweren kann. Nichtsdestotrotz ist das Vektorraummodell das zur Zeit am weitesten entwickelte Modell mit relativ einfacher Bedienung auf Seiten des Benutzers und sehr guter Retrieval-Qualität. Entmutigend ist jedoch, dass in fast keinem kommerziellen System das Vektorraummodell zur Anwendung kommt. Lediglich einige wissenschaftlich gepflegte IR-Systeme, z.b. an Universitäten, verwenden das Vektorraummodell. Das wohl bekannteste und älteste System ist das SMART-System, welches von Gerard Salton und seinen Mitarbeitern ins Leben gerufen wurde [SJM87] Ausblick auf die Zukunft Wie im vorigen Abschnitt bereits geschildert, werden heute ausschließlich die Modelle verwendet, die einen nicht-probabilistischen Ansatz verfolgen. Diese Systeme werden mit Sicherheit weiter gepflegt und verbessert werden, wenngleich man sagen muss, dass Systeme mit den Ansätzen Boolesches Retrieval, Ranking-Verfahren und Fuzzy-Retrieval allein vom konzeptionellen Aufbau her keine Kandidaten für ein effektives Retrieval im Informationszeitalter sind - geschweige denn für die Zukunft jemals sein werden. Die Informations-Flut in der heutigen Zeit ist enorm und wird in Zukunft sicherlich noch um ein vielfaches gesteigert werden. Der Trend hin zum "Globalen Netzwerk" ist unverkennbar, die Beschaffung von Information wird immer einfacher und für jedermann möglich. Daraus stellt sich einerseits die Forderung nach einfacher Bedienung, andererseits die Forderung nach guter Retrieval-Qualität an IR-Systeme, welche alle drei genannten Modelle

166 152 KAPITEL 10. INFORMATION RETRIEVAL nicht erfüllen können. Das Vektorraummodell bietet vom Konzept her viel Potential, jedoch stellt sich die Frage, wie das Modell arbeitet, wenn es im großen kommerziellen Umfeld eingesetzt wird, z.b. den Suchmaschinen im immer weiter wachsenden Internet. Das Vektorraummodell wird heute vornehmlich nur im wissenschaftlichen Bereich, oft lediglich zu Forschungszwecken benutzt. Wie das Modell reagiert, wenn tausende Benutzer gleichzeitig in einem riesigen Datenbestand suchen ist ungewiss. Trotzdem ist das Vektorraummodell wohl ein Kandidat für die Zukunft des Information Retrieval. Zumindest jedenfalls, bis die Forschung an den probabilistischen Modellen so weit fortgeschritten ist, dass erste Systeme mit diesen Modellen auch implementiert werden. Der probabilistische Ansatz ist auf jeden Fall sehr viel versprechend und könnte dem Vektorraummodell in der Zukunft den Rang als bestes Information Retrieval System ablaufen.

167 Kapitel 11 Metadaten Michael Klein Metadaten stellen Informationen über Dokumente zur Verfügung, mit deren Hilfe diese Dokumente identifiziert und auffindbar gemacht werden sollen. Dies ist gerade in Bezug auf Dokumente, die für eine breite Öffentlichkeit im Internet zugänglich sind, von großer Wichtigkeit. Mit Metadaten soll die Katalogisierung von Publikationen effizient und effektiv erreicht werden, um so ein gezieltes Auffinden von relevanten Informationen zu ermöglichen. Dieses Dokument gibt eine Motivation der Einführung von strukturierten Metadaten. Über die allgemeine Definition und Erläuterung von Metadaten hinaus, wird insbesondere auf den Dublin Core Element Set (DC) der Dublin Core Metadata Initiative sowie das Resource Description Framework (RDF) des W3 Consortiums näher eingegangen. 153

168 154 KAPITEL 11. METADATEN 11.1 Einleitung Die Zunahme der Nutzer des Internets sowie die damit verbundene Vielfalt der im Internet zur Verfügung gestellten Dokumente machen es immer schwieriger gezielt an für den jeweiligen Zweck relevante Informationen zu gelangen. Die verbreitete Praxis der Volltext-Indizierung erweist sich häufig, gerade bei der Suche nach wissenschaftlichen Themen, als unzureichend, um Dokumente klassifizierbar und retrievalfähig zu machen. Etablierte Suchmaschinen wie AltaVista oder Lycos verfolgen den Ansatz, vom Benutzer eingegebene Stichworte mit den indexierten Dokumenten zu matchen, was häufig genug zu einer Vielzahl unbrauchbarer vermeindlicher Treffer führt. " Um vernünftige Lösungsstrategien zur automatisierten Suche nach Internetdokumenten anzubieten, ist es notwendig eine präzisere Beschreibung eben dieser Dokumente bereitzustellen. Metadaten, also Informationen über Informationen, können dies leisten, indem sie Angaben wie Autor, Titel, Datum, Schlüsselworte idealerweise sogar in das Dokument eingebettet kennzeichnen und somit auslesbar machen. Wohldefinierte Metadatensätze, wie z.b. der im Bibliothekswesen zur Katalogisierung eingesetzte Standard MARC (Machine-Readable Cataloging), bieten eine Vielzahl von Elementen zur Beschreibung von Dokumenten, eignen sich jedoch häufig aufgrund ihres hohen Zeitaufwands bei der Erstellung und Pflege wenn überhaupt nur bedingt zur Anwendung in Bezug auf Internetdokumente. Auf den folgenden Seiten wird eine Einführung in das Thema Metadaten gegeben. Einleitend werden Internetdokumente charakterisiert, indem die Unterschiede zu herkömmlichen Publikationsformen wie Büchern, Zeitschriften, CDs, Videofilme etc. herausgestellt werden. In diesem Zusammenhang wird auch auf die Katalogisierung im Bibliothekswesen eingegangen. Nach einer Erläuterung des Begriffs Metadaten wird ihr Sinn und Zweck anhand ihrer Funktionen, der Vorteile und einer Unterscheidung ihrer Typen beschrieben. Von verschiedenen Metadatenformaten, die hier nur genannt werden, sollen jedoch zwei näher vorgestellt werden. Zum einen ist dies der Dublin Core Element Set (DC) der Dublin Core Metadata Initiative [Ini99], zum anderen das Resource Description Framework (RDF) des W3 Consortiums [W3C99], dessen Spezifikation es erlaubt, verschiedene Metadatenformate zur Beschreibung von Dokumenten heranzuziehen Charakterisierung von Internetdokumenten An dieser Stelle soll herausgearbeitet werden, welche Merkmale Internetdokumente von physikalischen Dokumenten unterscheiden. D.h. welche Informationen zur Beschreibung von Publikationen im Internet notwendig sind, die im Bibliothekswesen eher eine untergeordnete Rolle spielen Katalogisierung in herkömmlichen Bibliotheken Wenn wir Metadaten im weitesten Sinne als " Daten über Daten verstehen, könnte man die Datensätze eines Bibliothekskataloges sicherlich auch als Metadaten betrachten. Eta-

169 11.2. CHARAKTERISIERUNG VON INTERNETDOKUMENTEN 155 bliert hat sich der Begriff Metadaten jedoch bei der Beschreibung von digitalen Informationen durch strukturierte Datensätze, die insbesondere auch Aufschluß über den Aufbewahrungsort des referenzierten Dokuments liefern. Genau hier liegt auch das signifikanteste Merkmal von Katalogen einer Bibliothek wie sie in jeder größeren Stadt zu finden ist. Es wird lediglich der Bestand einer Institution erfaßt, womit sich Informationen über den Ort, an dem sich ein Buch oder eine Zeitschrift befindet, auf die Angabe des Regalplatzes beschränken. Informationen darüber, wie man dorthin gelangt, oder welche Mittel und Voraussetzungen man dazu benötigt, sucht man vergebens. Bei der Suche nach einem Thema findet man möglicherweise den gleichen Artikel in verschiedenen Zeitschriften oder auch einen Videofilm. Für jedes dieser Suchergebnisse hält der Katalog einen eigenen Eintrag bereit, aber selten enthalten die Datensätze direkte Verweise auf andere Informationsquellen zu dem gleichen Thema. Als letztes Merkmal sei hier genannt, daß Bücher, Zeitschriften, Fotos, Videos, CDs etc., eben alle Informationsquellen, die eine Bibliothek bereitstellt, als ganzes beschrieben werden. Die Datensätze enthalten keinerlei Hinweise auf das Kapitel oder sogar die Seite, in der man das gesuchte Thema findet und die einzige Möglichkeit, aus dem Gesamtwerk nur den Abschnitt zu extrahieren, der für einen selbst von Interesse ist, ist das Fotokopieren der Seiten Kriterien zur Beschreibung von digitalen Dokumenten In gewisser Weise ähnelt die Katalogisierung von Internetdokumenten der Vorgehensweise bei der Erfassung von Dokumenten in einer Bibliothek. Eine Sammlung von Metadatensätzen könnte man als Bibliothekskatalog auffassen, der sich auf verschiedene Bibliotheken bezieht. Die Flut an Informationen, die schon heute im Internet bereit stehen, macht es jedoch notwendig, weitere Kriterien bei ihrer Erfassung anzusetzen, die auch angesichts des enormen Wachstums der Internetnutzung den Zweck der Katalogisierung erfüllen: Relevante Informationen schnell und vor allem präziese zu finden und zur Verfügung zu stellen, und das weitestgehend automatisiert. Rachel Heery gliedert in dem Artikel Review of Metadata Formats [Hee96] die Charakteristika von Netzwerk Ressourcen in sechs Bereiche: Locations: Wie schon im vorherigen Abschnitt beschrieben, beziehen sich Bibliothekskataloge auf nur eine Institution. Strukturierte Metadaten müssen eine Möglichkeit bieten verschiedene Zielorte, an denen die Dokumente abgelegt sind zu referenzieren. Dies geschieht i.a. durch die Angabe der URL. Document versions: Liegt ein Dokument in verschiedenen Formaten, wie z.b. Postscript und Html vor, könnte es von Vorteil sein, beide Versionen in einem Datensatz zu beschreiben. Zwei unterschiedliche Druckversionen würde man als zwei verschiedene Ausgaben betrachten. Lack of stability: Dateien bleiben häufig nicht sehr lange an einem Ort gespeichert. Ihre URLs veralten und führen ins Leere oder, was oft noch irritierender ist, sie

170 156 KAPITEL 11. METADATEN verweisen auf völlig andere Seiten. Es kommt ebenso vor, daß Dokumente, die schon publiziert sind, von den Autoren überarbeitet werden und somit ständig Änderungen unterliegen. Dem Nutzer sollte durch die Metadaten bzw. durch die Dienste, die diese Daten verarbeiten, die Möglichkeit gegeben werden, eine Art Qualitätskontrolle in Bezug auf den Status des Dokuments durchzuführen. Redundant Data: Das Internet als " aktuelles Medium beinhaltet aktuelle Informationen. Diese Tatsache bedeutet allerdings auch, daß manches, was gestern noch dem Stand der Technik entsprach, heute seine Gültigkeit verloren hat aber dennoch mit dem Anschein der Aktualität im Netz verbleibt. Wünschenswert wären hier Informationen zur Überprüfung der Gültigkeit der Dokumente oder gar die Bereitstellung von Informationen über Aktualisierungen. Granularity: Versuche, die im traditionellen Bibliothekswesen benutzten Kataloge in einem feineren Detaillierungsgrad zu erstellen, erwiesen sich als nicht praktikabel für Werke, die sich nur mit einem Thema befassen. Eine Indexierung auf der Ebene des Inhaltsverzeichnisses macht kaum Sinn und etablierte Datensatzformate wie MARC sehen dies auch nicht vor. Eine allen Bedürfnissen gerecht werdende Beschreibung von Internetseiten erfordert jedoch häufig eine Erfassung auf einer tieferen Ebene, in der jedes Thema eines Dokuments referenziert wird, das für unterschiedliche Personenkreise von Interesse seien kann. Nature of location data: Für den Zugriff auf Dokumente im Internet reicht es nicht aus lediglich die URL anzugeben, da so keinerlei Zugriffsbeschränkungen erkennbar sind. Es werden also Informationen über verschiedene Zugriffsprotokolle wie z.b. FTP, HTTP benötigt sowie eventuelle Schutzmechanismen wie Paßwortabfragen Metadaten zur Beschreibung von Internetdokumenten Bestehende Methoden zur Erfassung von Internetressourcen, wie die von fast allen kommerziellen Suchmaschinen benutzte Volltextindexierung, sind bei der Menge an Dokumenten, die heute schon im Internet zur Verfügung stehen, nicht mehr zeitgemäß. Die damit zu erzielende Genauigkeit läßt gerade bei wissenschaftlichen Anwendern zu wünschen übrig. Einen strukturierteren Ansatz liefern hier Metadaten. In diesem Kapitel soll der Begriff Metadaten anhand ihrer Funktionen und ihrer praktischen Vorteile näher erläutert werden. Eine Typisierung soll dann die funktionalen Aspekte von Metadaten näher differenzieren. Abschließend gibt ein Abschnitt über die Repräsentation von Metadaten einen Überblick über ihren Gebrauch Metadaten - was ist das? Metadaten dienen der Beschreibung von Dokumenten, aber auch anderen digitalen Objekten (oft wird hier von document-like-objects gesprochen). Sie sind dem eigentlichen

171 11.3. METADATEN ZUR BESCHREIBUNG VON INTERNETDOKUMENTEN 157 Inhalt eines Dokuments übergeordnet und enthalten Information wie Titel, Autor, Thema, Sprache etc. des Dokuments. Häufig sind diese Informationen Bestandteil des zu beschreibenden Objekts, es können aber auch Informationen sein, die sich nicht direkt im Dokument wiederfinden. Dies sind z.b. Angaben über den Aufbewahrungsort, das Format oder Beziehungen zu anderen Dokumenten. Solche Beziehungen lassen sich beispielsweise durch Attributnamen wie " vertieft in oder " entnommen aus kennzeichnen und als Elemente in entsprechende Metadatensätze aufnehmen. Eine Reihe weiterer Elemente zur Beschreibung und Katalogisierung von Dokumenten sind denkbar und in bestehenden formalen Standards, wie dem von der Library of Congress entwickelten USMARC, spezifiziert. Derartig detaillierte Datensätze erweisen sich jedoch aufgrund ihres hohen Pflegeaufwandes als unpraktikabel für den Einsatz im Internet Funktionen von Metadaten In erster Linie dienen Metadaten dazu, Objekte und Informationen identifizierbar zu machen. Sie liefern Angaben, die es ermöglichen ein Dokument in eindeutiger Weise zu referenzieren. Darauf aufbauend können mit den über eine Anzahl von Dokumenten in strukturierten Datensätzen gesammelten Informationen Kataloge erstellt werden, ob in gedruckter oder digitaler Form in einer Datenbank. Der für den Internetnutzer wichtigste Aspekt ist sicherlich der, daß es ihm mit Hilfe von auf Metadaten zurückgreifenden Suchdiensten auf eine sehr einfache Art und Weise möglich ist, die für ihn relevanten Informationen schnell und präzise finden und abrufen zu können. Zusammenfassen läßt sich dies unter dem Begriff 'Information Retrieval'. Ein möglichst hoher Automatisierungsgrad ist hierbei angesichts der Dokumentenvielfalt im Internet unverzichtbar Vorteile von Metadaten Wie bei allen Neuentwicklungen ist eine hohe Akzeptanz bei den Nutzern auch für die Etablierung von Metadatenstandards unverzichtbar. Dies erreicht man jedoch nur, wenn die neuen Methoden Vorteile gegenüber Althergebrachtem bieten und diese Vorteile nicht durch einen übermäßigen Mehraufwand kompensiert werden. Verschiedene Metadatenstandards, die schon heute in ihrer Entwicklung weit fortgeschritten sind, sind einfach zu handhaben, da sie nur auf die nötigsten Beschreibungselemente zurückgreifen. Diese Elemente lassen sich außerdem einfach in Html-Dokumente einbinden. Optionalität und Flexibilität im Detaillierungsgrad lassen dem Verfasser von Internetdokumenten hier Freiheiten bei der Beschreibung seiner Werke. Nur das was er für wichtig hält braucht, er auch anzugeben. Die eindeutige Definition und eine standardisierte Syntax der Metadatenelemente bieten die Voraussetzung für ein präzises 'Information Retrieval'. Die Informationsfilterung im Internet kann so auch wissenschaftlichen Ansprüchen genügen.

172 158 KAPITEL 11. METADATEN Zusammenhänge zwischen verschiedenen Dokumenten lassen sich durch Metadaten abbilden. Dabei kann es sich um inhaltliche, thematische, aktuelle oder schöpferische Zusammenhänge handeln. Durch geeignete Standards lassen sich zum einen Anwendergruppenübergreifende, aber auch Anwendergruppenspezifische Metadatendefinitionen entwickeln, die den jeweiligen Bedürfnissen gerecht werden Typen von Metadaten Metadatenelemente lassen sich nach ihrer Funktion in verschiedene Typen unterscheiden. Zur Identifikation von Dokumenten dienen der Titel oder Elemente, die eine Identifikationsnummer oder einen anderen eindeutigen Bezeichner des Objekts enthalten. Empfohlen sind hier standardisierte Identifikatoren wie URIs (Uniform Resource Identifier) inklusive der URL (Uniform Resource Locator) oder eine ISBN-Nummer (International Standard Book Number). Andere Elemente liefern Informationen über Zugangsbedingungen und Nutzungsund Beschaffungskonditionen. Damit lassen sich Fragen beantworten wie: Benötigt man eine Registration bei einer Organisation um das Dokument abrufen zu können? Oder: Entstehen Kosten? In diese Kategorie lassen sich auch Formatangaben einordnen. Strukturelle Aspekte werden in Elementen verwaltet, die Angaben über Veknüpfungen zu anderen Dokumenten enthalten. Die Art der Beziehung wird dabei unterschieden. Kreative Leistungen wie Übersetzungen oder andere Darstellungsformen, historische und mechanische Beziehungen oder Versionsangaben sind ebenso denkbar, wie Verweise auf ein Gesamtwerk, aus dem das Dokument entnommen ist bzw. Verweise auf einzelne Auszüge aus dem Dokument. Der Inhalt und Kontext wird durch Elemente beschrieben, die das Thema, Stichwörter oder Kurzbeschreibungen enthalten. Sie dienen vor allem der Suche und Filterung von Dokumenten. Schließlich lassen sichnochangabenüber die Nutzungs- und Wirkungsgeschichte machen. Das betrifft die Herkunft eines Dokuments sowie seinen Verwendungszweck. Also Angaben darüber, ob es sich beispielsweise um ein Gedicht, einen technischen Bericht oder eine Diplomarbeit handelt Repräsentation von Metadaten Um Metadaten im Internet auf effiziente und effektive Art und Weise verarbeiten zu können benötigt man geeignete Formen für ihre Repräsentation. Dabei ist zu unterscheiden, ob es sich bei dem zu beschreibenden Dokument um einen Text, eine Grafikdatei, eine Musikdatei oder eine Videodatei handelt. Die jeweiligen Formate bieten hier teilweise Möglichkeiten die Beschreibung des Inhalts direkt mit der Datei mitzuliefern. Bei Dokumenten in Schriftform ist es vergleichsweise einfach, Elemente für bibliographische und andere Informationen einzubinden. Man kann Beschreibungselemente direkt

173 11.4. VERSCHIEDENE METADATENFORMATE 159 am Anfang des Textes mit einer wohldefinierten Syntax angeben, so daß entsprechende Algorithmen diese auslesen und für den Nutzer aufbereiten können. Für html-dokumente gibt es hierzu sogenannte Meta-Tags, die im Header des Dokuments stehen und von zahlreichen Suchdiensten verarbeitet werden. Das folgende Beispiel zeigt, wie mit einem Meta- Tag der Titel eines Dokuments angegeben werden kann. <META NAME="Title" CONTENT="Seminar Metadaten der Projektgruppe Werkzeuge fuer digitale Bibliotheken" (LANG=de)> Nicht ganz so einfach gestaltet sich die Angabe von Metadaten bei Dokumenten, die nicht im html-format vorliegen. Eine sinnvolle Möglichkeit ist, für das entsprechende Werk eine html-datei anzulegen, in der man wieder in Form von Meta-Tags eine Beschreibung ablegt. Eine Referenz auf die Datei darf hierbei natürlich nicht fehlen. Schließlich nutzen WWW-Server Metadaten zur Beschreibung ihrer Inhalte. Dabei werden die Datensätze in Datenbanken verwaltet, über die dann Suchanfragen gestellt werden können Verschiedene Metadatenformate Die verschiedenen Ansprüche, die an Metadaten gestellt werden, sind so zahlreich wie die unterschiedlichen Gruppen, die Metadaten nutzen. Auf vielen wissenschaftlichen Gebieten sind sehr spezielle Daten von Interesse und damit auch notwendig, um relevante Informationen präzise finden zu können. Aus diesem Grund kann man heute auf eine Vielzahl von Metadatenformaten zurückgreifen, von denen hier nur einige wichtige genannt und teilweise kurz beschrieben werden sollen. TEI: Text Encoding Initiative, entwickelt vom Virginia Text Center, USA. Die TEI Richtlinien schreiben vor, daß TEI-codierte Texte von einem Header angeführt werden, der den Inhalt des Dokuments beschreibt. Die TEI-header können aber auch separat in Datenbanken zum Aufbau von Katalogen für verteilte Informationssysteme verwendet werden. TEI eignet sich damit auch zur Beschreibung von Werken, die keine Textdokumente sind. IAFA / WHO IS++ Templates: Internet Anonymous Ftp Archive Templates, entwickelt von der IAFA Arbeitsgruppe des IETF (Internet Engineering Taskforce). IAFA Templates sollen einen effektiven Zugriff auf Ftp-Archive ermöglichen, indem sie ihren Inhalt und ihre Dienste beschreiben. Die Datensätze werden im ASCII- Format gespeichert und sind einfach zu erstellen. Die Syntax und Semantik zielt auf eine Automatisierte Katalogisierung und Indexierung. MARC: Machine-Readable Cataloging Beim MARC Standard handelt es sich um eine Gruppe von Formaten mit ähnlicher Datensatzstruktur und ähnlichen Methoden zur Verkettung von Datenelementen.

174 160 KAPITEL 11. METADATEN MARC dient zum Austausch von Datansätzen zwischen kooperierenden Bibliotheken. MARC-Datensätze eignen sich zwar zur Beschreibung von einer Vielzahl von Dingen, die eine Bibliothek vorhält, sind jedoch nicht auf die Verwaltung von Zugangsinformationen für Objekte außerhalb der Bibliothek ausgelegt. Aufgrund verschiedener nationaler Interessen und bestehender Strukturen bildeten sich im Laufe der Zeit lokale Ausprägungen des MARC Standards wie USMARC, UKMARC, DANMARC, AUSMARC und UNIMARC, um nur einige zu nennen. Ihnen allen gemein ist ihre hohe Komplexität und eine strenge Normierung in Bezug auf die Werte, die die Datenfelder aufnehmen dürfen. Zum Suchen und Abrufen von MARC-Datensätzen über das Internet stellt das Z39.50 Protokoll geeignete Methoden zur Verfügung. Dabei werden Suchanfragen von einem Z39.50 Client an einen Z39.50 Server geschickt, der dann seinerseits aus seiner MARC-Datenbank entsprechende Datensätze an den Client zurückschickt. Bestimmte Attribute des Z39.50 Protokolls geben dabei an, wie der Server die Suchanfrage verarbeiten soll. Informationen über den Zugang zu einem Dokument liefert dieses Protokoll jedoch nicht. Der Dublin Core Element Set (DC) sowie das Resource Description Framework (RDF) soll in den folgenden beiden Kapiteln näher behandelt werden Dublin Core Element Set (DC) Der Dublin Core Element Set [Ini99] ist eine Liste von Metadatenelementen, auf die man sich 1995 auf dem Metadatenworkshop des OCLC (Online Computer Library Center) und der NCSA (National Centre for Supercomputer Applications) geeinigt hat. Die Ziele des Workshops beschrieb Stuart Weibel [Wei95] als das Vorhaben, ein gemeinsames Verständnis für die Probleme und mögliche Lösungen bei den Beteiligten voranzubringen und einen gemeinsamen Konsens bei der Festlegung eines Kernsatzes von Metadatenelementen zur Beschreibung von Internetressourcen zu erzielen. Immerhin galt es in Dublin, Ohio, USA (daher der Name Dublin Core) 52 Teilnehmer aus den unterschiedlichsten Berufen, die irgendwie mit Metadaten arbeiten, zu vereinen. Diese heterogene Zusammensetzung ermöglichte aber, einen Datensatz zu definieren, der nicht zu komplex ist aber den Ansprüchen der verschiedensten Nutzergruppen gerecht werden kann Zielsetzungen Neben dem Wunsch, einen Satz von Metadatenelementen zu kreieren, der so klein wie möglich sein sollte und dennoch flexibel genug, um für ein breites Spektrum von Dokumenten verschiedener Bereiche die notwendigen Beschreibungselemente zu liefern, wurden weitere Zielsetzungen formuliert. Diese sind: Beschränkung auf das Wesentliche: In erster Linie soll sich der Dublin Core auf die wesentlichen Beschreibungselemente eines Dokuments beschränken. Dies sind solche, die sich direkt aus dem Dokument ableiten lassen, wie Thema, Inhalt, Autor

175 11.5. DUBLIN CORE ELEMENT SET (DC) Erst in zweiter Linie wird auf Aspekte wie entstehende Kosten und Zugangsbedingungen eingegangen. Erweiterbarkeit: Für Objekte, die mit nur wenigen Elementen nicht ausreichend beschrieben werden können, sollen Mechanismen zur Verfügung stehen, die es erlauben, zusätzliche Elemente einzubinden. Darüberhinaus soll dem Umstand Rechnung getragen werden, daß der Dublin Core im Laufe der Zeit verändert und erweitert werden wird, aber dennoch kompatibel zur ersten Fassung bleiben soll. Sytaxunabhängigkeit: Es sind ausdrücklich keine syntaktischen Regeln aufgestellt, die die gewünschte Flexibilität im Gebrauch des Dublin Core einschränken könnten. Die Möglichkeit der Einbindung des Dublin Core in andere bestehende Standards soll gewahrt bleiben. Optionalität: Alle Elemente sind optional. Manche Objekte benötigen nicht immer alle Beschreibungselemente, beispielsweise ist die Angabe einer Sprache als Information zu einem Bild völlig sinnlos. Es ist außerden kontraproduktiv, komplexe Beschreibungen zu verlangen, wenn der Autor diese zusammenstellen muß. Einer Abschreckung soll hier entgegengewirkt werden (eine einfache Beschreibung ist allemal besser als gar keine). Wiederholbarkeit: Jedes Element des Dublin Core kann beliebig oft wiederholt werden. Dies ist beispielsweise notwendig, sogar unverzichtbar, wenn ein Dokument mehrere Autoren hat. Modifizierbarkeit: Die Elemente des Dublin Core sind selbsterklärend. Es ist dennoch notwendig, daß die Definitionen den Bedürfnissen verschiedener Nutzergruppen gerecht werden. Dies wird erreicht, indem jedes Element durch sogenannte Qualifier in seiner Bedeutung modifiziert werden kann. Die Angabe solcher Qualifier ist wiederum optional. Fehlt ein Qualifier, so ist die ursprüngliche Bedeutung gemeint. Qualifier sind in der Regel von bekannten Standards aus dem Bibliothekswesen abgeleitet oder entspringen dem Wissensgebiet des beschriebenen Objekts. Dadurch erhalten sowohl professionelle, als auch nicht professionelle Nutzer ihren Bedürfnissen entsprechende Möglichkeiten zur Beschreibung ihrer Werke Die Attribute der Dublin Core Elemente Jedes der Elemente Des Dublin Core Element Set nach Version 1.1 [Ini99] wird über Standardisierte Attribute definiert. Diese Attribute sind der Norm ISO/IEC zur Beschreibung von Datenelementen entnommen. Es sind: Name: Der Name des Datenelements. Identifier: Ein eindeutiger Bezeichner des Elements (entspricht bei den meisten Fällen dem Namen) Version: Die Version der Spezifikation des Elements.

176 162 KAPITEL 11. METADATEN Registration Authority: Die Einrichtung, Organisation oder Gruppe, die berechtigt ist, ein Element zu registrieren. Language: Die Sprache, in der die Spezifikation des Datenelements verfaßt ist. Definition: Eine Darlegung, die das Konzept und den wesentlichen Charakter klar beschreibt. Obligation: Gibt an, ob das Element mit einen Wert belegt werden muß oder nicht. Datatype: Legt den Datentyp des von dem Element aufgenommenen Wertes fest. Maximum Occurrence: Die maximale Wiederholbarkeit eines Elements. Comment: Anmerkungen zur Verwendung des Datenelements. Sechs dieser zehn Attribute sind für alle Dublin Core Elemente gleich und haben die folgenden Werte: Version: 1.1 Registration Authority: Dublin Core Metadata Initiative Language: en Obligation: optional Datatype: Character String Maximum Occurrence: unlimited Die übrigen vier individuellen Attribute sind zur formalen Definition jedes Dublin Core Elements im folgenden Abschnitt angegeben Die Elemente des Dublin Core An dieser Stelle sollen die 15 Elemente des Dublin Core Element Set nach der englischen Spezifikation in [Ini99] definiert und erklärt werden. Die Definition und der Kommentar sind sinngemäß ins Deutsche übersetzt. Element: Title Name: Identifier: Definition: Comment: Title Title Der Name des Werkes / der Quelle. " Ein Titel, unter dem das Dokument formell " bekannt ist.

177 11.5. DUBLIN CORE ELEMENT SET (DC) 163 Element: Creator Name: Identifier: Definition: Comment: Creator Creator Eine Rechtspersönlichkeit,die für den Inhalt des " Dokuments in erster Linie verantwortlich ist. Verfasser können Personen, Organisationen oder " Gruppen seien z.b. Autoren, Maler, Fotografen, Vereine, Behörden... Element: Subject Name: Identifier: Definition: Comment: Subject and Keywords Subject Das Thema des Inhalts der Quelle. " Ein Thema wird durch Schlüsselworte, Phrasen " oder Klassifikationen nach bestimmten Schemata beschrieben. Element: Description Name: Identifier: Definition: Comment: Description Description Eine Beschreibung des Inhalts der Quelle. " Eine Beschreibung kann in Form eines freien " Textes, einer Inhaltsangabe oder Inhaltsverzeichnisses gegeben werden. Element: Publisher Name: Identifier: Definition: Comment: Publisher Publisher Eine für die Veröffentlichung der Quelle " verantwortliche Rechtsperson. Ein Verleger kann eine Person, eine Organisation oder " eine andere Gruppe sein. Element: Contributor Name: Identifier: Definition: Comment: Contributor Contributor Eine Person, die einen Beitrag zu der Quelle " geleistet hat. Mit beteiligte Personen sind auch Organisationen " oder andere Gruppen gemeint.

178 164 KAPITEL 11. METADATEN Element: Date Name: Identifier: Definition: Comment: Date Date Ein Datum, das mit einem Ereignis im " Lebenszyklus der Quelle verbunden ist. Das Datum der Fertigstellung oder der Veröffentlichung " des Dokuments. Empfohlen wird die Angabe des Datums nach der Norm ISO 8601 im Format JJJJ-MM-DD. Element: Type Name: Identifier: Definition: Comment: Resource Type Type Der Typ oder das Genre des Inhalts der Quelle. " Der Typ beinhaltet Begriffe für die Beschreibung von " Kategorien, Funktionen etc..empfohlen wird die Verwendung eines standardisierten Vokabulars. Element: Format Name: Identifier: Definition: Comment: Format Format Das physikalische oder digitale Format der Quelle " Als Format wird der Medientyp oder die Größe des " Werkes angegeben. Es wird zur Bestimmung der zur Betrachtung des Dokuments benötigen Soft- bzw. Hardware verwendet. Die Angabe eines Formats aus der Liste für Internet Media Types (MIME) wird empfohlen Element: Identifier Name: Identifier: Definition: Comment: Resource Identifier Identifier Eine in einem Kontext eindeutige Referenz " der Quelle. Empfohlen wird, ein Dokument durch einen String " oder eine Nummer aus einem formalen Identifikationssystem zu referenzieren. Beispielsweise sind hier der Uniform Resource Identifier (URI) zusammen mit dem Uniform Resource Locator (URL), der Digital Object Identifier (DOI) oder die International Standard Book Number (ISBN) zu verwenden.

179 11.5. DUBLIN CORE ELEMENT SET (DC) 165 Element: Source Name: Identifier: Definition: Comment: Source Source Eine Referenz auf ein Werk, von dem das " beschriebene Dokument abgeleitet ist. Das beschriebene Dokument kann von einem " anderen Dokument abgeleitet sein. Dieses wird am besten durch einen String oder eine Nummer wie für das Element Identifier referenziert. Element: Language Name: Identifier: Definition: Comment: Language Language Die Sprache, in der der Inhalt des Dokuments " verfaßt ist. Empfohlen ist die Verwendung von Werten aus dem " Standard RFC 1766 (abgeleitet aus der Norm ISO 639), der einen zweistelligen Sprachcode bereitstellt. Für Englisch ist dies 'en', Französisch 'fr' oder für britisches Englisch 'en-uk'. Element: Relation Name: Identifier: Definition: Comment: Relation Relation Eine Referenz auf ein Werk, das mit der " beschriebenen Quelle in Verbindung steht. Das beschriebene Dokument kann mit einem " anderen Dokument in Beziehung stehen. Dieses wird am besten durch einen String oder eine Nummer wie für das Element 'Identifier' referenziert. Element: Coverage Name: Identifier: Definition: Comment: Coverage Coverage Der Umfang oder das Gebiet des Inhalts der Quelle. " Der Bereich umfaßt in der Regel räumliche " Ausdehnungen (ein Platz, Name oder Koordinaten), zeitliche Perioden oder auch Zuständigkeitsbereiche wie administrative Einrichtungen.

180 166 KAPITEL 11. METADATEN Element: Rights Name: Identifier: Definition: Comment: Rights Management Rights Informationen über Rechte an der Quelle " oder an Teilen in der Quelle. Rechtliche Informationen in Form von Statements " über das Dokument, oder Verweise auf Institutionen, die rechtliche Informationen über das Dokument bereitstellen. Rechtliche Informationen umfassen Rechte über geistiges Eigentum, Copyright Informationen und andere verschiedene Eigentümerrechte. Für die Elemente des Dublin Core stehen drei verschiedene Qualifier zur Verfügung, um präzisere Informationen bereitzustellen [RF98]: LANG bezeichnet die Sprache des Inhalts der Meta-Information und wird sowohl bei der Suche als auch bei der Filterung von Suchergebnissen genutzt. Ein Beispiel für die Syntax sind die folgenden Meta-Tags: <META=DC.Title, CONTENT="Review of Metadata Formats"(LANG=en> <META=DC.Title, CONTENT="Vergleich von Metadaten Standards"(LANG=de> SCHEME bezeichnet Standards, Regeln und Normen, nach denen der Wert eines Beschreibungselements entnommen ist. Ein Beispiel hierfür ist: <META=DC.Subject, CONTENT=(SCHEME=DDC)"370.15"> SUB-ELEMENT verfeinert und präzisiert einige der Elemente. Beispielsweise sind verschiedene Sub-Elemente für das 'Date' Element nützlich: <META=DC.Date.Created, CONTENT=" "> <META=DC.Date.Published, CONTENT=" "> <META=DC.Date.Accepted, CONTENT=" ">... Ebenso gilt dies für die Elemente 'Relation' und 'Coverage', auf die an dieser Stelle nicht näher eingegangen werden soll. Der Dublin Core Element Set bietet also gerade bei Beschreibung von Internetdokumenten Vorteile aufgrund seines einfachen Aufbaus. Die Elemente sind in in den Header aufzunehmen und auch von Html-Werkzeugen zu verwalten, so daß man nicht zwingend Html beherrschen muß, um seine Dokumente mit Metainformation zu versehen. Dublin Core wurde außerdem bereits von einer Anzahl von Institutionen implementiert und kann auf eine breite, internationale Akzeptanz zurückgreifen.

181 11.6. RESOURCE DESCRIPTION FRAMEWORK (RDF) Resource Description Framework (RDF) Die ersten Entwürfe des Resource Description Framework (RDF) veröffentlichte das World Wide Web Consortium Man wollte Mechanismen bereitstellen, die eine Verarbeitung von Metadaten ermöglichen. Die Automatisierung bei der Nutzbarmachung der Vielfalt von Internetdokumenten stand hierbei im Vordergrund. RDF soll für den Einsatz in unterschiedlichen Anwendungen probate Mittel zur Verfügung stellen. Angefangen bei der Verbesserung von Suchmaschinen in Bezug auf die Qualität der Suchergebnisse, über den Einsatz bei der Katalogisierung zur Beschreibung von Inhalten und Beziehungen zu anderen Dokumenten, bei der Beschreibung von verknüpften Seiten, die ein zusammenhängendes Dokument bilden, bei intelligenten Software Agenten, die 'knowledge sharing' und den Austausch von Informationen erleichtern bis hin zur Klassifizierung und Bewertung von Werken im Internet. Schließlich soll der Einsatz von digitalen Signaturen zusammen mit RDF die Sicherheit im Internet für electronic commerce und ähnliche sicherheitsrelevante Anwendungen fördern Was ist RDF? RDF ist eine deklarative Sprache zur Beschreibung von elektronischen Ressourcen. Gemeint sind damit Dinge, die mit einem URI referenzierbar sind. RDF bedient sich der Syntax von XML (extensible Markup Language) ohne dabei Annahmen über ein bestimmtes Anwendungsgebiet vorauszusetzen. Auch kennt RFD keinen speziellen vordefinierten Wortschatz zur Beschreibung von Metadaten, sondern bietet die Möglichkeit verschiedene Standards einzubinden oder gar neue Schemata zu definieren. Der grundlegende Gedanke bei RDF ist der einer Sprache, mit der man Aussagen über Dinge trifft, die mittels gerichteter Graphen modelliert werden können. Diese Graphen bestehen aus Knoten, zugehörigen Paaren von Attributen und Werten. Knoten sind beispielsweise Quellen im Internet, Attribute sind die Eigenschaften der Knoten, deren Werte entweder atomar sind (also Text Strings oder Zahlen) oder wiederum Quellen bzw. Dokumente mit Attributen. Solche Modelle werden dann mittels XML speicherbar und austauschbar repräsentiert Das grundlegende RDF Modell Das RDF zugrundeliegende Modell stützt sich auf bewährte Ausdrucksweisen etablierter Datenbeschreibungsstandards. Eigenschaften von Ressourcen werden durch Paare von Attributen und Werten beschrieben. Eigenschaften können außerdem Beziehungen zwischen Ressourcen repräsentieren. Verfolgt man hierbei den objektorientierten Ansatz, kann man anstelle von Ressourcen von Objekten und anstelle von Eigenschaften von Variablen ihrer Instanzen sprechen. Das grundlegende RDF Modell kennt drei verschiedene Objekttypen: Resources: Alles, was mittels RDF Ausdrücken beschrieben wird, wird als Ressource bezeichnet. Das kann ein Html-Dokument, mehrere verlinkte Internetseiten oder nur

182 168 KAPITEL 11. METADATEN ein Teil einer Seite sein. Ebenso sind beispielsweise gedruckte Bücher Ressourcen wie jedes Werk, das mit einem URI referenziert werden kann. Properties: Als Eigenschaft einer Ressource können spezielle Charakteristika, Attribute oder Beziehungen zu anderen Ressourcen gelten. Die spezifischen Bedeutungen der Eigenschaften legen fest, welche Werte sie annehmen können. Statement: Eine Ressource zusammen mit ihren benannten Eigenschaften und den zugehörigen Werten bildet schließlich ein sogenanntes RDF Statement. Die drei Teile eines Statements werden in Anlehnung an die Grammatik mit Subjekt, Prädikat und Objekt bezeichnet. Das Objekt (der Wert der Eigenschaft) eines RDF Statements kann also eine andere Ressource, ein einfacher Text String, ein Literal oder ein anderer einfacher Datentyp sein. Abbildung 11.1: Die Struktur eines RDF Statements als gerichteter Graph Abbildung 11.2: Ein RDF Statement als gerichteter Graph mit analogen Bezeichnern. Die Abbildungen 11.1 und 11.2 zeigen ein RDF Statement als Graph Modellierung eines RDF Statements Das in Abbildung 11.3 gezeigte kleine Beispiel eines Statements kann gelesen werden als: Werner Muster verfaßte die home-page am 11. " November Abbildung 11.3: Beispiel eines Statements als gerichteter Graph. Das Beispiel unter Verwendung der XML Syntax lautet:

183 11.6. RESOURCE DESCRIPTION FRAMEWORK (RDF) 169 <? xml version="1.0"?> <RDF xmlns:rdf = " xmlns:s = " > <Description about = " > <s:creator> Werner Muster </s:creator> <s:date> </s:date> </Description> </RDF> Die este Zeile bezeichnet die zu verwendende XML Version. Dann wird der XMLnamespace (xmlns) referenziert, der in der RDF Syntaxdefinition unter der angegebenen URL beschrieben ist. Das Metadatenschema wird durch das Präfix 's' gekennzeichnet und der xmlns assoziiert es mit der Internetadresse der 'description organisation' (die frei erfunden ist). 'Description about' bezeichnet die Ressource, über die Informationen angegeben werden. Das 's' vor den Tags 'Creator' und 'Date' referenziert dann das Schema in dem die Eigenschaften Creator und Date und ihre zulässigen Werte spezifiziert sind RDF und Dublin Core Anhand des folgenden Beispiels soll an zwei Elementen des Dublin Core exemplarisch gezeigt werden, wie über ein RDF Schema Metadatenstandards aufgebaut und definiert werden können. <?xml version='1.0'?> <rdf:rdf xmlns:rdf= " xmlns:rdfs= " xmlns:dc=""> <rdf:description about = ""> <dc:title> The Dublin Core Element Set </dc:title> <dc:creator> The Dublin Core Metadata Initiative </dc:creator> <dc:description> The Dublin Core is a simple metadata element set intended to facilitate discovery of electronic resources. </dc:description> <dc:date> </dc:date> </rdf:description>...

184 170 KAPITEL 11. METADATEN Als erstes werden wieder die xmlns Attribute gesetzt. Das 'Description' Tag nimmt eine Beschreibung des vorliegenden Dokuments, also des DC Schemas auf. Die eigentlichen DC Elemente werden wie folgt definiert:... <rdf:description ID="Title"> <rdf:type rdf:resource= " <rdfs:label>title</rdfs:label> <rdfs:comment>the name given to the resource, usually by the Creator or Publisher.</rdfs:comment> <rdfs:isdefinedby rdf:resource = ""/> </rdf:description> <rdf:description ID="Creator"> <rdf:type rdf:resource= " <rdfs:label>author/creator</rdfs:label> <rdfs:comment>the person or organization primarily responsible for creating the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources. </rdfs:comment> <rdfs:isdefinedby rdf:resource = ""/> </rdf:description>... Die 'Description ID' identifiziert das zu definierende DC Element. Sein Typ wird als 'Property', also als Eigenschaft festgelegt, die einen Namen erhält. Der Kommentar gibt Aufschluß über die Verwendung Abschließende Anmerkungen Die Notwendigkeit, zwischen den zahlreichen bestehenden Metadatenstandards einen Konsens zu schaffen, um die Informationsflut im Internet überschaubarer zu machen, ist unumstritten. Doch scheitern Versuche in dieser Richtung noch allzu häufig an den unterschiedlichen Bedürfnissen der Anwender. Einer breiteren Akzeptanz von standardisierten Metadaten stehen die in vielen Fällen zu hohe Komplexität der Datensätze im Wege. Nicht Jeder braucht dutzende von Elementen zur Beschreibung seiner Dokumente, aber Anderen genügen die gebräuchlichsten nicht. Optionalität, wie sie der Dublin Core Element Set liefert, scheint hier Abhilfe schaffen zu können. Eine gut funktionierende automatisierte Verarbeitung der Daten bedarf jedoch strengen Regularien für die Werte der Elemente.

185 11.7. ABSCHLIESSENDE ANMERKUNGEN 171 Insgesamt läßt sich feststellen, daß insbesondere der Dublin Core in steigendem Maße Anwendung im wissenschaftlichen Bereich findet während andere Standards wie MARC und TEI ihre Stellung behalten werden. Überaschender war die Feststellung, daß die wenigsten Dokumente, die sich iminternet mit Metadaten auseinandersetzen, auch tatsächlich Metadaten bereitstellen. Den notwendigen Aufwand hierfür scheinen bislang nur professionelle Institute wie Bibliotheken und Forschungseinrichtungen wie Universitäten betreiben zu wollen.

186 172 KAPITEL 11. METADATEN

187 Kapitel 12 XML Tobias Ottenhues Diese Ausarbeitung zum Thema XML und dem Bezug von XML zu Java wurdeim Rahmen der Seminar-Phase der Projekt-Gruppe Entwicklung von Werkzeugen für digitale Bibliotheken angefertigt. In den ersten Kapiteln wird eine kurze allgemeine Einführung in XML gegeben und insbesondere auf Teilaspekte wie DTD", DOM", CSS und XSL" näher eingegangen. Anhand eines Beispiels wird die Thematik etwas näher gebracht. Anschließend widmet sich ein Kapitel MathML, einer Anwendung von XML. Der zweite Teil beschäftigt sich dann mit dem Bezug von XML zu Java. Nach dem Vorstellen von Gemeinsamkeiten wird auf den Verarbeitungszyklus eines XML-Dokuments eingegangen. Anschließend werden ein paar java-basierte Werkzeuge für XML vorgestellt und das Kapitel mit einem anschaulichen Beispiel abgeschlossen. In der Literatur- & Link-Liste wird weiterführende Literatur zu den Themengebieten aus dem WWW angeboten. 173

188 174 KAPITEL 12. XML 12.1 Einleitung In den letzten Wochen und Monaten hörte man oft Begriffe wie XML, DTD, CSS, usw. Was aber verbirgt sich hinter diesen Abkürzungen? XML steht für extensible Markup Language" (zu deutsch: ausdehnbare oder erweiterbare Auszeichnungssprache). Die Idee, die hinter XML steht, ist, ähnlich wie bei HTML, die Auszeichnung von Daten im Textformat unter Zuhilfenahme von so genannten Tags 1. Des weiteren sollten XML-Dokumente sowohl für Menschen als auch von Maschinen (wie z.b. Computern oder Programmen) lesbar und auswertbar sein. Zur Zeit findet man im Internet in der Regel Dokumente, die hauptsächlich von Menschen auswertbar und lesbar sind. Ein Computer(-programm) kann zum Beispiel in einem im WWW veröffentlichten Buch nicht so ohne Weiteres den Namen des Autors ausfindig machen, da dieser in dem Dokument meist nicht ausgezeichnet ist und sich dementsprechend irgendwo im Text befinden kann. Um diesen Umstand zu ändern, ist eine semantische Auszeichnung von Elementen, das so genannte Markup, notwendig. XML definiert deshalb eine abstrakte Semantik", die die Wahl der Präsentation und der Interpretation der Auszeichnungen dem Empfänger offen lässt. Das folgende XML in 10 Punkten" ist eine freie Übersetzung eines Textes des W3C[W3Cd] (World Wide Web Consortium) und soll dem Leser eine kurze grobe Einführung in die Grundkonzepte von XML geben XML in 10 Punkten (Naja, eigentlich sind es ja nur sieben Punkte, die im folgenden aufgeführt werden, aber zehn hört sich besser an.) XML ist eine Methode, um strukturierte Daten in eine Textdatei umzuwandeln Unter strukturierten Daten versteht man zum Beispiel Tabellen, Adressbücher, Konfigurationsparameter, technische Zeichnungen oder strukturierte Texte, wie zum Beispiel ein Buch, das aus einzelnen Kapiteln und Überschriften und vielleicht einem Anhang und einem Literaturverzeichnis besteht. Programme, mit denen solche Daten erstellt werden, speichern diese entweder binär oder im Textformat ab. Letzteres erlaubt es, sich die Daten auch ohne die Benutzung des Programms, welches sie generiert hat, anschauen zu können. XML ist ein Regelwerk oder eine Menge von Konventionen, um strukturierte Daten in eine Textdatei umzuwandeln. Dies soll auf eine Art und Weise geschehen, dass sie einfach von Computern generiert und ausgewertet werden können. 1 Markierung in einem Dokument, um Formate zu bestimmen, die über den einfachen Text hinausgehen, wie z.b. Hypertext-Links, Hervorhebungen, Tabellen oder auch Java-Applets.

189 12.1. EINLEITUNG XML sieht ein bisschen aus wie HTML - ist aber kein HTML XML benutzt ebenso wie HTML Tags" und Attribute", um den Text dazwischen auszuzeichnen. Dabei bleibt die Interpretation der Tags dem Lesenden - ob Computer oder Mensch - überlassen. Wenn man zum Beispiel in einem XML-Dokument ein <p>-tag" vorfindet, muss es nicht notwendigerweise ein Paragraph-Tag sein. Je nach Zusammenhang kann es zum Beispiel ein Preis, ein Parameter, eine Person oder sonst was sein (wer sagt überhaupt, dass es ein Wort mit P sein muss?) XML ist Text, der aber nicht dazu gedacht ist, ihn zu lesen. XML-Files sind Text-Files, aber sie sind nicht unbedingt dazu da, um von Menschen gelesen zu werden, sondern vielmehr um von Maschinen oder Programmen gelesen oder ausgewertet zu werden. Da in Zukunft immer mehr Aufgaben von Computern oder Programmen übernommen werden, stellt XML gerade dieses einfache Textformat hierfür zur Verfügung. Dadurch dass XML-Files reine Text-Files sind, sind sie leicht zu debuggen 2 und man benötigt lediglich einen einfachen Texteditor, um sie gegebenenfalls zu ändern. Die Regeln von XML sind sehr viel strenger gefasst, als dies bei HTML der Fall ist, worauf im weiteren Verlauf noch eingegangen wird XML ist eine Familie" von Technologien Zum einen gibt es XML 1.0. Dies ist die Spezifikation, die definiert, was Tags" und Attribute" sind. Zum anderen gibt es noch eine ganze Reihe von optionalen Modulen, die weitere Features von XML darstellen. Um nur ein paar zu nennen: ffl CSS - die Style-Sheet-Language, die zum Gestalten der XML-Dokumente benutzt wird, wie sie auch schon in HTML manchmal zur Anwendung kommt. ffl XSL - die advanced Styling Language" - dt.: fortgeschrittene Layout-Sprache - dient dazu, das Layout der Dokumente auszuzeichnen. ffl DOM ist eine Menge von Funktionen, um XML (und auch HTML) unter Zuhilfenahme von Programmiersprachen, wie zum Beispiel Java, manipulieren zu können. ffl DTD definiert das Regelwerk" für die Struktur eines XML-Dokuments. ffl XLink (zur Zeit noch in der Entwicklung befindlich) beschreibt einen Standard, um Hyperlinks oder andere Relationen zwischen Dokumenten in XML fassen zu können. ffl Namespaces - eine Spezifikation, die beschreibt, wie man mittels einer URL jedes einzelne Attribut und jeden Tag in einem XML-Dokument ansprechen kann. Wozu diese URLs dann benutzt werden, bleibt dann der Applikation, die sie liest, überlassen. 2 Fehler-Verfolgung und -Beseitigung

190 176 KAPITEL 12. XML ffl XML Schemata 1 und 2 dienen Entwicklern, um ihr eigenes XML-Format genau definieren zu können. Auf einige der genannten Module wird in den folgenden Kapiteln noch einmal etwas genauer eingegangen XML ist wortreich, aber das ist kein Problem XML-Dateien sind etwas größer als vergleichbare binäre Formate, da sie einige zusätzliche Tags" beinhalten. Die Entwickler von XML haben dies bewusst in Kauf genommen. Die Vorteile des Text-Formats sind augenscheinlich (siehe Punkt 3) und die Nachteile kann man heutzutage fast vernachlässigen, da es immer größere und günstigere Festplatten auf dem Markt zu erwerben gibt und es ebenfalls eine Reihe guter Programme wie zip oder gzip gibt, die besonders solche reinen Text-Dateien gut und schnell komprimieren können XML ist neu - aber so neu auch wieder nicht Die Entwicklung von XML begann bereits Seit Februar 1998 ist XML ein W3C- Standard. Die Technologie von XML gab es allerdings schon viel früher - in den 80er Jahren entstand bereits SGML (Standard Generalized Markup Language), die sich aber nicht in der Masse durchsetzen konnte. Lediglich in der Industrie kam sie hin und wieder zur Anwendung. XML entstand aus HTML und SGML, wobei die Entwickler von XML einfach von jedem die besten Teile nahmen. Einen kleinen Einblick in die Historie von XML liefert das nächste Teil-Kapitel XML ist Lizenz-frei, Plattform-unabhängig und gut unterstützt XML ist Lizenz-frei: Jeder kann sich eigene Software um XML herum bauen und braucht niemandem etwas dafür zu zahlen. XML ist Plattform-unabhängig: Durch Verwendung des reinen Textformats können XML- Dateien auf verschiedenen Plattformen (wie zum Beispiel UNIX, Windows, usw.) weiter verwendet werden. XML ist gut unterstützt: Es gibt eine Menge von Werkzeugen zur Verarbeitung von XML und viele Leute kennen sich bereits mit XML aus und können bei Fragen meistens helfen. Außerdem gibt es bereits eine Vielzahl an Informationen zum Thema XML im WWW.

191 12.1. EINLEITUNG Historie von XML Ende 1960 entstand zum ersten Mal das Konzept des Generalized Markups", was allerdings erst mit SGML (1986) zum Standard wurde. In dieser Zeit gewann das Internet immer mehr an Akzeptanz als Medium für den Austausch von Informationen, das so genannte information retrieval". Hierfür entstand dann um 1992 HTML als Sprache für das WWW kamen dann die ersten Entwicklungen von XML auf, weil HTML den gestiegenen Ansprüchen nicht mehr ganz entsprach und die Browser-Hersteller wie Microsoft oder Netscape in der Auswahl der HTML-Tags keinen einheitlichen Standard mehr folgten und es so zu Inkompatibilität der HTML-Dokumente kam, die nur für einen bestimmten Browser optimiert waren. Zum Beispiel kann man mit dem Marquee-Tag im InternetExplorer eine Laufschrift erkennen, während dieses im Netscape-Browser nicht der Fall ist. Dieses hatte zur Folge, dass die Entwicklung von Dokumenten für sämtliche Browser nur auf einem niedrigen Level möglich war. Zudem wollte man die Dokumente des WWW in Zukunft nicht nur für Menschen lesbar gestalten, sondern auch Maschinen wie Computer oder Applikationen sollten diese lesen, auswerten und gegebenenfalls manipulieren können. Im Februar 1998 wurde XML dann zum W3C-Standard. XML stellt die Next-Generation- Sprache" für das Internet dar Der Zweck von XML Der Zweck von XML lässt sich an den folgenden 5 Punkten festhalten: ffl Schaffung eines standardisierten Textformats für das Internet. ffl Datenformat zur Einbettung von strukturierten Daten. ffl Selbstbeschreibungsfähigkeit der Informationen. ffl Daten Maschinen-lesbar / -auswertbar. ffl Trennung von Daten und Darstellungsinformationen. XML sollte ein standardisiertes Textformat bieten, was von allen Browser-Typen gleichermaßen interpretiert wird. Ebenfalls sollte XML ein Textformat darstellen, welches zur Einbettung von strukturierten Daten in der Lage sei. Zum Beispiel sollten mittels XML Daten einer Datenbank (z.b. ein Adressbuch) über das Internet vermittelt werden können. Die Informationen in einem XML-Dokument sollten durch die Auszeichnung mittels Tags selbst-beschreibend sein; das heißt der Tag-Name sollte beschreiben, was zwischen dem entsprechenden Anfangs- und Ende-Tag steht. Ein Beispiel: Der Autor eines Buches wird normalerweise einfach irgendwo im Text genannt. Wie soll ein Programm, welches z.b. eine Datenbank mit Autoren zu Büchern füttern" soll, diesen in dem Dokument finden?

192 178 KAPITEL 12. XML Lösung: Hier würde man sich in XML einfach eines neuen Tags bedienen, welcher in diesem Fall z.b. folgendermaßen aussehen könnte: <autor>nicholas Evens</autor> Die Daten eines XML-Dokuments sollten Maschinen-lesbar und -auswertbar sein. Dies ist mittels der Auszeichnung von Abschnitten durch die Tags möglich. Das Programm (z.b. ein Parser) kann das Dokument anhand der Tags auswerten. Stößt z.b. der Parser im obigen Beispiel auf das Autor"-Tag, so schließt er daraus, dass es sich bei dem Inhalt um den Autor des Dokuments handelt. Somit ist es ein leichtes, aus verschiedenen Dokumenten die Autoren herauszufiltern und in einer Datenbank Buchtitel und Autor zu verwalten. Ein weiterer wichtiger Aspekt bei XML ist die Trennung von Daten und Darstellungsinformationen. So lassen sich leicht die Daten oder die Darstellungsinformationen ändern. Möchte man z.b. in einem Dokument sämtliche Überschriften in einer anderen Farbe dargestellt haben, so musste man in einem HTML-Dokument diese Änderung bei jeder Überschrift einzeln ändern. Bei einem XML-Dokument ändert man einfach nur die Darstellungsinformation für das Überschrift-Tag. Ähnlich wie bei Compilern kann man so für ein und das selbe Dokument verschiedene Darstellungsinformationen definieren - zum Beispiel für die Ausgabe als HTML-Datei, als PS-Datei für den Drucker, als PDF, usw.

193 12.2. XML DOKUMENTE XML Dokumente Dieses Kapitel soll anhand eines Beispiels den Unterschied zwischen HTML- und XML- Dokumenten erläutern und einen kleinen Blick auf die Notation von XML-Dokumenten werfen. Außerdem folgt am Ende dieses Kapitels noch ein Abschnitt über well-formed" und gültige XML-Dokumente HTML-Beispiel Der folgende HTML-Code (Abb. 12.1) beschreibt ein Rezept. Dieses Rezept besteht u.a. aus einem Namen, den Zutaten und einer Beschreibung, wie man das Rezept zubereiten sollte. <HTML> <HEAD> <TITLE> Lime Jello Marshmello Cottage Cheese Surprise </TITLE> </HEAD> <BODY> <H3>Lime Jello Marshmello Cottage Cheese Surprise</H3> My grandma's favorite (may she rest in pease). <H4>Ingrediens</H4> <TABLE BORDER=''1''> <TR BGCOLOR=''#308030''><TH>Qty</TH><TH>Units</TH> <TH>Item</TH></TR> <TR><TD> 1 </TD><TD>box</TD> <TD>lime gelantine</td></tr> <TR><TD>500</TD><TD>g</TD> <TD>multicolored tiny marshmellows</td></tr> <TR><TD>500</TD><TD>ml</TD> <TD>cottage cheese</td></tr> <TR><TD></TD><TD>dash</TD> <TD>Tabasco sauce (optional)</td></tr> </TABLE> <P> <H4>Instructions</H4> <OL> <LI>Prepare lime gelatin according to package instructions...</li> <!-- and so on --> </BODY> </HTML> Abbildung 12.1: HTML-Code des Beispiels

194 180 KAPITEL 12. XML Die Ausgabe dieses HTML-Beispiels ist in Abb dargestellt. Abbildung 12.2: HTML-Ausgabe des Beispiel-Codes Hier werden die Zutaten für das Rezept in einer Tabelle dargestellt. Problem: Wie soll zum Beispiel ein Parser, der solche Rezept-Dateien durchsucht und die Rezepte in einer Datenbank ablegt, feststellen, wo in dem Dokument z.b. die Bezeichnung einer Zutat steht. Dies kann ja durchaus in verschiedenen Dokumenten an unterschiedlichen Orten stehen, so dass sich die Suche danach kaum automatisieren lässt. Es wäre eine enorme Arbeit, immer erst die oberste Zeile einer Tabelle zu durchforsten, um festzustellen, was denn nun in welcher Spalte der Tabelle abgelegt wurde - geschweige denn, wenn dieses nicht mal in der obersten Zeile spezifiziert würde. Um die Verarbeitung solcher Dokumente zu automatisieren kann man auf XML zurückgreifen, da XML geradezu ideal für die strukturelle Auswertung geeignet ist.

195 12.2. XML DOKUMENTE XML-Beispiel Zum Vergleich von HTML und XML zeigt Abb das selbe Beispiel von oben als XML-Dokument. Hier wird das ganze Rezept in Bestandteile einer Rezept-Beschreibung <?xml version=''1.0''?> <Recipe> <Name> Lime Jello Marshmellow Cottage Cheese Surprise </Name> <Description> My grandma's favorite (may she rest in peace). </Description> <Ingredients> <Ingredient> <Qty unit=''box''>1</qty> <Item>lime gelatin</item> </Ingredient> <Ingredient> <Qty unit=''g''>500</qty> <Item>multicolored tiny marshmellows</item> </Ingredient> <Ingredient> <Qty unit=''ml''>500</qty> <Item>Cottage cheese</item> </Ingredient> <Ingredient> <Qty unit=''dash''/> <Item optional=''1''>tabasco sauce</item> </Ingredient> </Ingredients> <Instructions> <Step> Prepare lime gelatin according to package instructions </Step> <!-- And so on --> </Instructions> </Recipe> Abbildung 12.3: XML-Code des Beispiels eingebettet. Ein Rezept hat einen Namen, besteht aus Zutaten und Instruktionen, wie das Rezept zubereitet werden muss. Die Instruktionen werden in verschiedene Schritte unterteilt, die Zutaten werden in einzelne Zutaten aufgeteilt, die aus einer Quantität mit dem Attribut der Einheiten (z.b. ml, g, box) und einem Item mit dem Namen der Zutat bestehen.

196 182 KAPITEL 12. XML XML-Notation - well-formed" - gültig" In diesem Teil-Kapitel wird ein kurzer Blick auf die Notation von XML-Dokumenten geworfen. Des weiteren wird geklärt, wann ein XML-Dokument well-formed" und wann es gültig ist well-formed" XML-Dokumente Das Konzept der well-formedness" ist der Mathematik entnommen. Es ist möglich mathematische Ausdrücke zubeschreiben, die keinerlei Bedeutung haben. Zum Beispiel sieht der folgende Ausdruck (Gleichung 12.1) aus, wie ein mathematischer Ausdruck, aber er ist es nicht, weil er nicht den Notations- und Strukturregeln der Mathematik entspricht - zu mindestens nicht hier auf der Erde. Mit anderen Worten, dieser Ausdruck ist nicht well-formed". 2(+ + 5(=)9 > 7 (12.1) Ein well-formed" XML-Dokument hält sich also an die Notation und Strukturregeln von XML. Im Gegensatz zu HTML müssen in XML sämtliche Tags mit einem End-Tag abgeschlossen werden (s. Abb. 12.4). Abbildung 12.4: Start- und End-Tag Leere" Tags sehen in XML so aus, wie es Abb zeigt. Wie in HTML können innerhalb der Tags nochattribute angegeben werden, dessen Werte immer in Hochkommatas" eingeschlossen sind. Ein XML-Dokument ist well-formed", also wohl geformt oder entspricht dem XML- Standard, wenn es die folgenden vier Bedingungen erfüllt:

197 12.2. XML DOKUMENTE 183 Abbildung 12.5: Empty-Tag ffl es darf keine ungeschlossenen Tags geben, d.h. dass sämtliche Tags mit einem End- Tag abgeschlossen werden müssen bzw. die Definition eines leeren" Tags muss eingehalten werden. ffl die Tags dürfen sich nicht überlappen; es sind also nur ineinander verschachtelte Tags erlaubt. ffl sämtliche Attribut-Werte müssen(!) in Hoch-Kommata stehen. ffl es muss möglich sein, die folgenden Sonderzeichen in XML darstellen zu können: (<), (>) und( ) Hierfür stellt XML die folgenden Befehle" bereit: (<), (>) und ("). Anhand von ein paar Beispielen soll deutlich werden, was in XML nicht erlaubt ist: ffl In HTML wird zum Beispiel das <LI>-Tag niemals mit </LI> abgeschlossen. In XML ist der Gebrauch solcher Tags nicht erlaubt. XML-Dokumente sollten als Datenstrukturen (Bäume) darstellbar sein, worauf das folgende Kapitel über das Document Object Model DOM" eingehen wird. ffl <H1><B>Dies ist eine fettgedruckte Überschrift</H1> Dieser Text ist auch noch fettgedruckt.</b> Der Rest ist wieder normal gedruckt. Dieser Gebrauch der Verschachtelung einzelner Tags ist in XML nicht erlaubt, da das <B>-Tag innerhalb des <H1>-Tags geöffnet wird, aber nicht wieder geschlossen wird. XML-konform würde das Beispiel folgendermaßen aussehen: <B> <H1>Dies ist eine fettgedruckte Überschrift</H1> Dieser Text ist auch noch fettgedruckt. </B> Der Rest ist wieder normal gedruckt. Um es auf einen Punkt zu bringen: Die Struktur von XML-Dokumenten muss streng hierarchisch sein. well-formed" bedeutet auch, daß das XML-Dokument von einem Parser auf Korrektheit geprüft werden kann. XML-Parser gibt es von verschiedenen Herstellern - in Java

198 184 KAPITEL 12. XML geschriebene XML-Parser gibt es im WWW gratis. Sie arbeiten ähnlich wie Compiler und erzeugen Fehlermeldungen, wenn das XML-Dokument nicht well-formed" ist. Die validating XML Parser" gehen noch einen Schritt weiter Gültigkeit von XML-Dokumenten Validating XML Parser" überprüfen neben der wellformedness" zusätzlich noch, ob das XML-Dokument gültig ist. Ein XML-Dokument ist gültig, wenn es well-formed" ist und zusätzlichnoch die Struktur und die Anzahl der Tags Sinn machen. Dies soll noch mal anhand eines kleinen Beispiels deutlich gemacht werden: <Ingredient> <Qty unit="ml">500</qty> <Qty unit="g">9</qty> <Item>Cottage cheese</item> </Ingredient> Dieses Dokument ist zwar well-formed", aber die Struktur macht keinen Sinn, denn in diesem Beispiel wird nichts über die Zutat ausgesagt - dieser Teil fehlt nach dem ersten <Qty>-Tag völlig. Dies zeigt also, daß es XML-Dokumente gibt, welche zwar well-formed" sind, bei denen allerdings die Struktur keinen Sinn macht. Es wird also einen Mechanismus benötigt, um zu definieren, wann ein XML-Dokument gültig ist - also eine Technik, um die Struktur eines XML-Dokuments zu definieren. Die Document Type Definition DTD beinhaltet im Falle von XML diesen Mechanismus, auf den das nächste Kapitel näher eingehen wird DTD - Document Type Definition Eines der wichtigsten Merkmale, die XML von SGML geerbt hat, ist das Konzept der Document Type Definition", kurz DTD. So wie ein wohlgeformtes" XML-Dokument well-formed" ist, weil es den Regeln der XML-Spezifikation folgt, so ist ein XML-Dokument gültig, wenn es den Struktur-Regeln in seiner DTD folgt. Die DTD ist ein optionales, aber sehr mächtiges Feature von XML, dessen Regelwerk die Struktur eines XML-Dokuments definiert Was ist die DTD und wozu dient sie? Eine DTD beschreibt also die Grammatik für das XML-Dokument im speziellen Fall. Allgemein beschreibt die DTD die Grammatik einer beliebigen Auszeichnungssprache (Markup Language (ML)). So gibt es zum Beispiel auch für HTML eine eigene DTD. In der DTD wird festgelegt, welche Tags in einem gültigen Dokument enthalten sind und wie sie ineinander verschachtelt werden dürfen, welche Attribute sie haben können und

199 12.3. DTD - DOCUMENT TYPE DEFINITION 185 welche Attribute überhaupt Sinn machen. Das Beispiel mit den zwei aufeinanderfolgenden <Qty>-Tags aus dem letzten Kapitel ist hierfür ein gutes Beispiel. Die Struktur macht keinen Sinn. Ein ( validating") Parser kann mittels der DTD feststellen, ob ein XML-Dokument gültig ist, oder nicht. Die DTD definiert also den Dokument-Typ. Das erklärt auch das extensible" in XML. Mit jeder neuen DTD schafft man sozusagen eine neue Auszeichnungssprache (ML). Bisher gibt es schon ein paar neue spezielle MLs, die jeweils für ein spezielles Gebiet optimiert sind. Hier wären zu nennen: ffl MathML ffl CML ffl cxml Wie der Name schon sagt, ist MathML eine mathematische Auszeichnungssprache, auf die noch im 6. Kapitel als Anwendung von XML etwas genauer eingegangen wird. CML steht für Chemical Markup Language". Sie dient also speziell für den Bereich Chemie. cxml steht für commercial XML". Sie ist speziell für den Bereich des e-commerce konzipiert worden Einbindung in XML Die Einbindung einer DTD in ein XML-Dokument kann auf zweierlei Arten geschehen: ffl inline ffl über eine Referenz im Dokument ffl beides Im Falle der inline-einbindung wird die komplette Document Type Definition oben in den Kopf des XML-Dokuments eingetragen. Dies geschiet in der 2. Zeile - direkt nach dem <?XML Version="1.0">. <!DOCTYPE RECIPE [ <!ELEMENT Recipe(Name,Description?,Ingredients?,Instructions?)>... and so on... ]> Auf die Erklärung der Syntax und Semantik wird im folgenden noch etwas eingegangen. Im zweiten Fall, der Einbindung der DTD über eine Referenz, wird im XML-Dokument

200 186 KAPITEL 12. XML lediglich ein Verweis auf das entsprechende externe DTD-File eingefügt. Dies geschieht an der selben Stelle, an der im ersten Fall die interne Einbindung stattgefunden hat: <!DOCTYPE Recipe SYSTEM ``example.dtd''> In diesem Beispiel (Abb. 12.6) steht die DTD in der Datei example.dtd". Zu guter Letzt gibt es auch noch die Kombination von interner Einbindung und externem DTD-File. In diesem Fall hat die interne Einbindung Vorrang vor der externen DTD. In diesem Fall überprüft der Parser zunächst die internen Regeln und benutzt erst dann die Regeln aus der externen DTD, wenn er intern keinen Match bekommt DTD - Ein Beispiel <!-- Dies ist eine Beispiel DTD für das XML-Beispiel --> <!ELEMENT Recipe (Name, Description?, Ingredients?, Instructions?)> <!ELEMENT Name (#PCDATA)> <!ELEMENT Description (#PCDATA)> <!ELEMENT Ingredients (Ingredient) Λ > <!ELEMENT Ingredient (Qty, Item)> <!ELEMENT Qty (#PCDATA)> <!ATTLIST Qty unit CDATA #REQUIRED> <!ELEMENT Item (#PCDATA)> <!ATTLIST Item optional CDATA ``0''> <!ELEMENT Instructions (Step) + >...? = optional + = ein oder mehrmals * = null oder mehrmals PCDATA = character data Abbildung 12.6: Ausschnitt aus der Beispiel-DTD Das obige Beispiel (Abb. 12.6) ist ein Ausschnitt aus der DTD für das weiter oben gebrachte XML-Beispiel (Abb. 12.3). Die Definitionen funktionieren ähnlich, wie es von den Regeln zur Syntaxbeschreibung z.b. bei Programmiersprachen bekannt sein dürfte. In der zweiten Zeile wird definiert, wie ein Recipe strukturell auszusehen hat: Es hat einen Namen und anschließend noch optional eine Beschreibung, Zutaten und Zubereitungsinstruktionen. Der Name und die Beschreibung bestehen nur aus Zeichen vom Typ Character (#PCDATA). In Zeile 5 wird definiert, was innerhalb des <Ingredients>-Tags stehen darf. Zutaten können natürlich eine Liste von Zutaten sein (es müssen keine Zutaten angegeben werden, aber es können beliebig viele Zutaten angegeben werden). Dies drückt das Sternchen aus. Eine einzelne Zutat (Ingredient besteht aus einer Menge (Qty) und aus einer Beschreibung der Zutat (Item). Diese werden in den folgenden Zeilen des Beispiels noch näher bestimmt. Die Menge hat ein Attribut Einheit (unit), welches auf jeden Fall

201 12.3. DTD - DOCUMENT TYPE DEFINITION 187 angegeben werden muss. Zusätzlich kann man dann innerhalb des <Qty unit="xxx">- Tags noch eine Wert für diese Einheit angeben, was aber zum Beispiel bei der Angabe eine Prise Salz" nicht unbedingt notwendig ist. Innerhalb des <Item>-Tags kann man auch nochzusätzlich alsattribut angeben, ob diese Zutat optional ist oder nicht (Default- Wert="0"). Die Zubereitungsinstruktionen bestehen aus einem oder mehreren Schritten ((Step) + ) usw. Ein Parser, der ein XML-Dokument auf Gültigkeit überprüft, geht die DTD Schritt für Schritt durch und prüft, ob das XML-Dokument den Regeln, die dort definiert wurden, entspricht. Ist dies nicht der Fall, so ist es kein gültiges XML-Dokument und es wird eine Fehlermeldung ausgegeben. Nachdem in diesem Kapitel die Struktur von XML-Dokumenten etwas näher gebracht wurde, beschäftigt sich das folgende Kapitel mit der Modellierung dieser Struktur.

202 188 KAPITEL 12. XML 12.4 DOM - Document Object Model Bislang wurden XML-Dokumente nur von dem Standpunkt aus betrachtet, daß sie für menschliche Wesen zum Lesen geeignet sind. Aber die wahre Stärke von XML ist die Fähigkeit, die Struktur der Information zu repräsentieren wie verschiedene Informationen zueinander gehören in ähnlicher Weise, wie es auch bei Datenbanken der Fall ist. Das Document Object Model (DOM) stellt die (meist baumartige) Repräsentation der Daten eines XML-Dokuments oder auch eines HTML-Dokuments dar. Ein DOM- Parser verarbeitet das XML-Dokument als Eingabe und erzeugt daraus einen Parsebaum. Für das Beispiel aus den vorigen Kapiteln (Abb. 12.3) sieht der Parsebaum dann folgendermaßen aus (Abb. 12.7): Abbildung 12.7: Baumartige Repräsentation des Beispiels Das Document Object Model" modelliert also die Informationsstruktur und stellt anderen Applikationen eine Schnittstelle zur Verfügung, um darauf zuzugreifen. Eine der ersten Anwendungen, die das Document Object Model benutzten, war Dynamic HTML, wo auf der Client-Seite Scripts ein HTML-Dokument manipulierten und neu darstellten je nach dem, welche Aktion der Benutzer gerade ausgeführt hatte. Das DOM ist somit ein nützliches Hilfsmittel für Applikationen, die diese Informationsstruktur verarbeiten oder zum Beispiel den Parsebaum verändern wollen. Man könnte sich zum Beispiel eine automatische Umwandlung eines XML-Dokuments ind einen Objekt- Baum oder umgekehrt vorstellen. Das hätte den Vorteil, daß man in Zukunft seine XML- Dokumente nicht mehr nur auf rein textueller Ebene in einem einfachen Editor editieren könnte, sondern auch direkt auf der Informationsstruktur arbeiten könnte. Es wäre zum Beispiel denkbar, mittels geeigneter Programme eventuell sogar mittels Drag & Drop die Objekte eines Parsebaums umordnen oder ändern zu können, so daß am Ende wieder ein gültiges XML-Dokument nach der Umwandlung des Objekt-Baums entsteht.

203 12.5. CSS / XSL STYLE SHEETS 189 Die folgende Grafik (Abb. 12.8) zeigt wie aus einem alten XML-Dokument durch Manipulation des Objekt-Baumes (DOM-trees) ein neues XML-Dokument entstehen kann. Abbildung 12.8: automatische XML-Dokument-Umwandlung Nachdem in den bisherigen Kapiteln eine Menge Informationen zu Struktur, Kontrolle und Überprüfung von XML-Dokumenten beschrieben wurde, wird es im nächsten Kapitel um die Darstellung von XML-Dokumenten gehen CSS / XSL Style Sheets In diesem Kapitel geht es um die Darstellung der XML-Dokumente. Bei CSS und XSL handelt es sich um die sogenannten Style-Languages" für XML. Mittels dieser Style- Sheets werden die Darstellungsinformationen des XML-Dokuments festgelegt. Unter den Darstellungsinformationen versteht man das Layout für die einzelnen Teile eines XML- Dokuments, wie zum Beispiel Stil, Farbe, Größe,... der Informationen, wie zum Beispiel einer Überschrift. Nachdem nun grob geklärt ist, wozu diese Style-Sheets denn gut sind, gibt es noch ein paar offene Fragen: ffl Was bedeutet CSS und wozu ist CSS gut? ffl Was bedeutet XSL und wozu ist XSL gut? Antworten auf diese Fragen versuchen die folgenden Abschnitte zu liefern CSS Die Abkürzung CSS steht für Cascading Style Sheets". Cascading Style Sheets werden heutzutage auch schon in HTML verwendet und werden dementsprechend von den Browser der heutigen Generation meist unterstützt. Die Wirkung der Cascading Style Sheets zielt auf alle folgenden gleichnamigen Tags im Dokument. Zum Beispiel, wenn die Ausgabe des Textes innerhalb eines Paragraph-Tags (<p>) auf rot" gesetzt wird, erscheint der komplette Text des Paragraphen ab dieser Stelle in rot, es sei denn, eines der nachfolgenden Tags ändert dieses wieder. Ähnlich einem Wasserfall wird die Änderung auf alle darunterliegenden Ebenen weiterpropagiert. Daher stammt

204 190 KAPITEL 12. XML auch der Ausdruck cascading" Style Sheets. Die Ausgabe ist bei den Cascading Style Sheets allerdings auf die Ausgabe des HTML- Formats beschränkt und es sind somit keine Datentransformationen zum Beispiel in ein anderes Textformat möglich. Wer dies wünscht, sollte XSL benutzen XSL Die Abkürzung XSL steht für extensible Stylesheet Language" wie schon bei XML ist XSL also auch ausdehnbar" oder erweiterbar". Das ist aber auch nicht verwunderlich, denn die Notation von XSL ist in XML gehalten. In XSL werden die Layoutinformationen in diesem Fall für XML-Dokumente beschrieben. Ein XSL-File enthält eine Menge von Regeln, den sogenannten Templates" (zu dt.: Schablonen), die für einzelne Tags die Layoutinformationen beinhalten. Mittels XSL ist ein Hinzufügen von zusätzlicher Struktur möglich: Beispielsweise könnte man bei einem <Adressbuch>-Tag dann für die HTML-Ausgabe noch hinzufügen: <H1><B>Mein Adressbuch</B></H1> Es entsteht natürlich auch eine neue oder erweiterte Struktur, indem der Text formatiert ausgegeben werden kann. XSL ist extrem mächtig. Neben dem Hinzufügen von zusätzlicher Struktur kann XLS auch die Eingabeelemente für einen bestimmten Zweck umordnen und umgestalten. Beispielsweise ist es mittels XML möglich, ein und dasselbe XML-Dokument in verschiedene andere Formate, wie HTML, LaTeX, PostScript, PDF etc. umzutransformieren, sofern es denn entsprechende XSL-Dateien gibt, die dieses gewährleisten. Im Notfall muss man sich einen solchen Konvertierer selbst schreiben. Desweiteren ist es möglich, ein XML-Dokument in verschiedene Dialekte zu transformieren. Das mag vielleicht komisch klingen, ist aber eine sehr interessante Idee. Beispiel: Gibt es zwei Systeme, die verschiedene XML-Dialekte benutzen, dann ist es mittels XSL möglich die Ausgabe des ersten Systems in eine kompatible Eingabe für das zweite System zu transformieren Interessantes für Java-Programmierer Besonders die zuletzt genannten Möglichkeiten von XSL sind für Java-Programmierer von ganz besonderem Interesse, da sie die Möglichkeit bieten, zwischen verschiedenen Sprachen zu übersetzen. Nachdem in den letzten fünf Kapiteln eine Menge über XML und seine optionalen Komponenten gesagt wurde, folgt nun in den nächsten beiden Kapiteln noch ein kurzer Blick auf MathML", als ein Anwendungsbeispiel von XML, und im letzten Kapitel wird kurz auf die Beziehungen und das Zusammenspiel" von XML und Java eingegangen.

205 12.6. ANWENDUNGSBEISPIEL: MATHML Anwendungsbeispiel: MathML Wie schon in Kapitel 3.1 beschrieben, gibt es bereits ein paar Anwendungsbeispiele von XML. Neben CML der Chemical Markup Language, speziell für den Chemiebereich und cxml dem commercial XML, speziell für den Bereich des gewöhnlichen Handels und des e(lectronic)commerce gibt es auch für den Bereich Mathematik und angrenzender Bereiche, die mathematische Notationen verwenden, die XML-Anwendung MathML, die hier kurz und repräsentativ für die anderen Anwengungen vorgestellt werden soll. MathML puts math on the web" - Diese Kernaussage (MathML bringt mathem. Notation ins Web) über MathML sagt eigentlich schon alles aus, worum es bei MathML geht. MathML ist eine Sprache zur Beschreibung mathematischer Notationen als Basis für die Maschine-Maschine-Kommunikation. Sie bietet eine gute Grundlage für das Einbetten von mathematischen Ausdrücken in Web-Seiten. Früher wurden mathematische Ausdrücke durch Schnappschüsse" aus anderen Applikationen in GIF's konvertiert und so in Web-Seiten eingebunden. Das W3C hat in einer eigenen Math Working Group" in Zusammenarbeit mit einer Reihe von Firmen und Spezialisten, die sich mit der Darstellung von mathematischer Notation auf Computern auskannten, versucht, diesen Mißstand zu beseitigen. Das Ergebis ist die mathemaische Auszeichnungssprache MathML Der Zweck von MathML Die Schaffung von MathML soll zu einer Erleichterung im Gebrauch und der Wiederverwendbarkeit von mathematischen und naturwissenschaftlichen Inhalten im Web und in anderen Applikationen, wie zum Beispiel Computer Algebra Systemen oder wissenschaftlicher Software, führen Ein kleines MathML-Beispiel Das folgende kleine Beispiel verdeutlicht hier kurz, wozu MathML im Stande ist: x 2 +4x +4=0 MathML bietet die Möglichkeit eine mathematische Formel auf zweierlei Weise in ein XML-Dokument einzubinden. Zum einen mittels darstellender Tags" und zum anderen mittels semantischer Tags".

206 192 KAPITEL 12. XML darstellende Tags : semantische Tags : <mrow> <mrow> <msup> <mi>x</mi><mn>2</mn> </msup> <mo>+</mo> <mrow> <mn>4</mn> <mo>&invisibletimes;</mo> <mi>x</mi> </mrow> <mo>+</mo> <mn>4</mn> </mrow> <mo>=</mo> <mn>0</mn> </mrow> <apply> <plus/> <apply> <power/> <ci>x</ci> <cn>2</cn> </apply> <apply> <times/> <cn>4</cn> <ci>x<ci> </apply> <cn>4</cn> </apply> Bei der Darstellung mittels darstellender Tags" wird die Gleichung (12.6.2) in einzelne Teile zerlegt, die innerhalb der <mrow>-tags stehen. Man kann sich das so vorstellen, daß man die eingeschlossenen Teile bei einer ganz ausführlichen Schreibweise einklammern könnte. Alle darstellenden Tags" beginnen mit m". o" steht für operator", also zum Beispiel +, -, *, /, =, usw., i" für identifier", also für Variablen, und das n" steht für number", also steht innerhalb des <mn>-tags eine Zahl, sup" steht für super", es dient also dazu, um das Potenzieren zu beschreiben. &invisibletimes;" bedeutet, daß in diesem Fall das eigentlich an dieser Stelle stehende Multiplikationszeichen nicht dargestellt wird, genauso wie man es bei manchen Formeln auch einfach wegläßt. Im Gegensatz zur darstellenden Version beschreiben die semantischen Tags" die Rechenoperationen, wie Addition (plus), Multiplikation (times), Potenzieren (power) und ist gleich" (apply). Das ci" und cn" steht wieder analog zum mo" und mn" für die Variablen und Zahlen. Welche Variante von MathML man benutzt ist freigestellt. Zum Auswerten oder Berechnen von Ergebnissen ist wahrscheinlich die semantische" Darstellung eher zu empfehlen. Kombiniert man MathML mit einem anderen Style-Sheet, um andere Aspekte des Layouts zu spezifizieren, so kann man evtl. MathML in Browsern benutzen, ohne irgendwelche Plug-ins benutzen zu müssen. Weitere Informationen zu den bislang behandelten Themengebieten findet man unter den entsprechenden Links im Literatur-Verzeichnis. Nach diesem kleinen Beispiel einer Anwendung von XML, interessiert sicherlich noch der Zusammenhang zwischen XML und Java, der im nächsten Kapitel kurz herausgestellt werden soll.

207 12.7. XML & JAVA XML & Java Möchte man eigene Applikationen für die Verarbeitung von XML-Dokumenten erstellen, so steht man vor der Frage: ffl Welche Programmiersprache und ffl welche Werkzeuge soll man dafür benutzen? Die Antwort lautet in diesem Fall JAVA, denn es gibt bereits eine ganze Reihe frei verfügbarer und leistungsfähiger java-basierter Werkzeuge, die speziell für die Verarbeitung von XML-Dokumenten geschaffen wurden. Dieses Kapitel zeigt zunächst die gemeinsamen Merkmale und die strukturellen Gemeinsamkeiten von XML und Java auf. Danach folgt eine Übersicht über den Verarbeitungszyklus eines XML-Dokuments, wobei besonders herausgestellt werden soll, in welchem Bereich die java-basierten Werkzeuge hauptsächlich anzutreffen sind, bevor am Ende dieses Kapitels einige wenige java-basierte Werkzeuge genannt werden und das Kapitel mit einem kleinen Beispiel abgerundet wird Was verbindet XML & Java Zu den bekanntesten Herstellern von Java-Software für XML zählen Firmen wie JavaSoft, Microsoft, Oracle und IBM. Dies zeigt schon, daß es sich bei dem Gespann XML/Java um ein strategisch wichtiges Thema handelt. Für die Verarbeitung von XML-Dokumenten mit Java sprechen eine ganze Menge von gemeinsamen Merkmalen: ffl XML wurde u.a. für den Einsatz im Web konzipiert. ffl Java ist eine wichtige Web-Technologie. ffl XML bietet portable Data, während Java mit seinem portable Code aufzutrumpfen weiß. ffl zusätzlich verbindet XML und Java noch die Verwendung von Unicode. XML ist auf den Unicode-Zeichensatz ausgelegt, während Java in den Quelltexten Unicode-Zeichen erlaubt und die Verarbeitung von Unicode-Zeichen in Programmen durch den Typ Char und zahlreiche Klassen in der Standardbibliothek unterstützt. Auch ein Blick auf die strukturellen Aspekte von XML und Java offenbart interessante Gemeinsamkeiten (s. Abb. 12.9): Bei XML definiert die DTD die Struktur, während bei Java die Klassen die Struktur festlegen. Ebenso wie bei XML zwischen der DTD und den Exemplaren einer DTD unterschieden wird, so unterscheidet man bei Javazwischen Klassen und den Exemplaren dieser Klassen. Aus der Baumhierarchie eines XML-Dokuments läßt sich ein Baum von Java-Objekten generieren. Die Attribute eines Elementknotens können auf die Attribute einer Java-Klasse abgebildet werden. Hierbei spricht man dann von den sogenannten XML-Beans".

208 194 KAPITEL 12. XML DTD () Java Klasen DTD / Exemplare einer DTD Klasse / Exemplare dieser Klasse Baumhierarchie =) Baum von Java-Objekten Attribute (Elementknoten) 7! Attribute (Java-Klasse) XML-Beans" Abbildung 12.9: strukturelle Gemeinsamkeiten von Java und XML Verarbeitungszyklus eines XML-Dokuments Anhand des Verarbeitungszyklus eines XML-Dokuments soll dargestellt werden, an welchen Stellen hauptsächlich Java-Programme und Applikationen in diesem anzutreffen sind. Der Verarbeitungszyklus eines XML-Dokuments besteht aus 4 Schritten: ffl Erstellung einer DTD ffl Erstellung eines Dokuments ffl Analyse mittels Parser ffl Verarbeitung des Parse-Baums in einer Applikation Die Erstellung einer DTD entspricht der Festlegung der Struktur des XML-Dokuments. Die Erstellung eines Dokuments liefert ein Exemplar der DTD, welches der in der DTD festgelegten Struktur entspricht. Die Analyse des Dokuments wird von einem Parser durchgeführt, der aus dem XML-Dokument einen Parse-Baum erzeugt, dessen Knoten die Bestandteile des Dokuments repräsentieren. Die Verarbeitung des Parse-Baums geschieht in einem Java-Programm oder einer Applikation, die die eigentliche Verarbeitungslogik enthält. Ein Beispiel für eine Applikation könnte beispielsweise ein Konvertierer sein, der ein XML-Dokument in das PDF- oder HTML-Format übersetzt oder eine Datenbank, die XML-Dokumente speichert und verwaltet. Die folgende Grafik (Abb ) verdeutlicht den Verarbeitungszyklus eines XML-Dokuments und stellt den Bereich heraus, der von java-basierten Werkzeugen hauptsächlich versorgt wird. Java-basierte Werkzeuge gibt es vorwiegend für die letzten beiden Stufen des Verarbeitungszyklus. Zwar gibt es auch Tools, die aus einer DTD einen visuellen Editor für Dokumente generieren können, die auf dieser DTD basieren, aber der Schwerpunkt liegt eindeutig auf dem Parsen und der Weiterverarbeitung. Bei der Entwicklung von XML-Applikationen hat man es hauptsächlich mit zwei Programmierschnittstellen zu tun: ffl DOM die Schnittstelle des Document Object Model" ffl SAX die simple API for XML" definiert den einheitlichen Zugriff auf den Parser.

209 12.7. XML & JAVA 195 DTD Exemplar Applikation Parser Parse-Baum Java Abbildung 12.10: Verarbeitungszyklus eines XML-Dokuments Allerdings würde es hier wohl den Rahmen sprengen, wenn man auf diese beiden Schnittstellen auch noch eingehen würde. Hier sei auf die weiterführenden Links im Literaturverzeichnis verwiesen Java-basierte Werkzeuge für XML Java-basierte Werkzeuge für XML sind heute bereits in enormer Bandbreite von verschiedensten Herstellern, größtenteils sogar kostenlos, verfügbar. Als Beispiele sollen hier nur exemplarisch einige wenige genannt werden, die hauptsächlich von IBM einem der wichtigsten Anbieter in diesem Bereich entwickelt worden sind [Mid99]: ffl XML4J Diese Distribution enthält eine DOM-Implementierung, einen Parser mit SAX-Treibern und seit neustem auch noch ein Framework für Applikationen. ffl XML Bean Maker Der XML Bean Maker" ist in der Lage, aus einer DTD Java-Klassen für den Parse-Baum generieren, die die einzelnen Elemente der DTD repräsentieren. ffl XML Diff and Merge Tool Das XML Diff and Merge Tool" kann Unterschiede zwischen XML-Dokumenten ermitteln und mit farblichen Hervorhebungen darstellen. ffl XML Security Suite Anhand bestimmter Merkmale eines XML-Dokuments, zum Beispiel von Attributwerten, kann die XML Security Suite" einen Hashcode" berechnen, welcher dann zusammen mit dem Dokument an den Empfänger übertragen werden kann. Der Empfänger ist dann mittels des Hashcodes in der Lage zu prüfen, ob das Dokument unverfälscht angekommen ist. ffl...

210 196 KAPITEL 12. XML Zum Abschluß des letzten Kapitels soll noch ein kleines Beispiel gegeben werden, welches die Verwendung der DOM-Schnittstelle anhand der Generierung eines Inhaltsverzeichnisses für ein Buch grob darstellt:

211 12.7. XML & JAVA Beispiel: Parser zur Inhaltsverzeichnisgenerierung Der folgende Code-Ausschnitt (Abb ) zeigt den groben Aufbau eines Buches. Ein Buch besteht aus mehreren Kapiteln, die wiederum Überschriften haben. Diese Überschriften sollen in die Inhaltsverzeichnisgenerierung einfliessen. <BOOK> <CHAPTER> <TITLE>Was ist XML?</TITLE>... </CHAPTER>... </BOOK> Abbildung 12.11: grober Aufbau eines Buches Nachdem nun bekannt ist, wie so ein Buch aufgebaut ist, zeigt der folgende Programmcode (Abb ), wie aus dem Dokument mittels der Methoden (die allesamt in der DOM- Schnittstelle definiert sind) die Titel herausgefiltert werden können. NodeList list = getelementsbytagname (``TITLE''); for (int i=0; i<list.length; i++) f titlenode = list.item(i); Text textnode = titlenode.getfirstchild(); String title = textnode.getdata(); // Titel ausgeben g Abbildung 12.12: Codeausschnitt: Parser zur Inhaltsverzeichnisgenerierung Das Dokument wird zunächst mal nach sämtlichen Vorkommen des Tags TITLE" durchsucht und diese in eine Liste vom Typ NodeList" abgespeichert. Anschließend wird diese Liste über eine FOR-Schleife durchlaufen und jeweils der Text, der innerhalb der TITLE-Tags steht extrahiert. Dieser kann dann in entsprechender Form z.b. als Inhaltsverzeichnis ausgegeben werden.

212 198 KAPITEL 12. XML 12.8 Abschließende Anmerkungen Die extensible Markup Language (XML) wird wohl in Zukunft noch populärer werden und früher oder später auch wohl HTML als Sprache des Internets ablösen. Die Vorteile von XML sind zum einen das einfache Textformat, die Trennung von Daten und den Formatierungsaspekten, die mittels CSS oder XSL je nach Situation hinzugefügt werden können. Zum anderen sind XML-Dokumente nicht nur von Menschen auswertbar, sondern auch Maschinen oder Computerprogramme können dieses Format gut auswerten, da gerade die semantischen Aspekte der Auszeichnung in XML Verwendung finden. Auch die Verbindung von XML und Java wird wohl in Zukunft noch mehr an Bedeutung gewinnen. XML und Java bilden ein starkes Team", da beide auf den Aspekt der Plattformunabhängigkeit aufsetzen und somit eine Integration von verschiedenen Systemen unterstützen. Weiterhin gibt es bereits eine Vielzahl an Java-Programmen zur Unterstützung von XML, wie zum Beispiel diverse Parser oder Applikationen. Bedauerlicherweise sieht es mit der Unterstützung durchdiebrowser-hersteller noch nicht so rosig aus. Der Internet-Explorer soll XML zum Teil schon unterstützen. Die nächste Browsergeneration sollte allerdings in der Lage sein, XML zu unterstützen. Zur Zeit gibt es aber nur wenig Unterstützung durch spezielle XML-Browser. Da der Themenbereich sehr umfassend ist, kann diese Ausarbeitung auch nur eine kurze Einführung in die Thematik von XML geben. Wer mehr zu dem Thema wissen möchte, dem sei die weiterführende Literatur und die WWW-Links empfohlen, die im Literaturverzeichnis angegeben sind. Zusätzlich lohnt sich auch hin und wieder ein Blick auf die folgenden WWW-Seiten, auf denen in letzter Zeit einige Artikel zum Thema XML und Java zu finden waren. ffl Unter gibt es oft interessante Veröffentlichungen zu XML und Java. ffl Ein Blick auf die WWW-Seite lohnt sich ebenfalls. ffl Unter gibt es einige interessante Informationen über XML, wie zum Beispiel Tutorials, Beispiele und Demos, Mailinglisten und Foren. ffl Unter dem Link findet man noch eine Menge Informationen über XML, wie zum Beispiel aktuelle News, Tools, Code, eine Bibliothek, etc. Mir persönlich hat die Beschäftigung mit diesem zukunftsweisenden Thema viele interessante neue Informationen über die Problematik gebracht. Ich hoffe, diese Ausarbeitung kann zumindest einen kleinen Einblick in das interessante Thema XML bieten.

213 Kapitel 13 Elektronischer Zahlungsverkehr im Internet Michael Malachinski Diese Ausarbeitung befasst sich mit Zahlungsweisen im Internet. Der Schwerpunkt liegt dabei auf den Verfahren, die eine Zahlung ohne Medienbruch erlauben (im Gegensatz zu den konventionellen Verfahren wie Rechnung oder Nachnahme). Zuerst werden sowohl die sicherheitstechnischen Anforderungen als auch die des Benutzers an solche Systeme erläutert. Für das bessere Verständnis der Umsetzung der Sicherheitsanforderungen wird auf die Grundlagen kryptographischer Verfahren eingegangen. Es folgt eine Klassifikation von Zahlungsverfahren nach unterschiedlichen Gesichtspunkten, in der auch die grundsätzlichen Konzepte elektronischer Zahlungsverfahren erläutert werden. Im Anschluss werden drei konkrete Zahlungsverfahren untersucht. Abschließend wird ein Blick in die Zukunft und auf die eventuelle Standardisierung elektronischer Zahlungsverfahren geworfen. 199

214 200 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET 13.1 Einleitung Das Internet hat in den vergangenen Jahren eine völlig neue Bedeutung erfahren: aus dem Informations- und Kommunikationsmedium für wenige " Eingeweihte wurde eine Spielwiese für ein Massenpublikum. Und die Zahl der Internetzugänge steigt weiter an. Dass das Internet ein unglaubliches Potenzial im Bereich des Marketings darstellt, haben kleine und große Firmen und Unternehmen längst erkannt. Während es den Unternehmen anfangs nur um die Präsenz im " neuen Medium ging, wird es inzwischen für völlig neue Formen des Marketings, insbesondere der Einzelwerbung, genutzt. Im Bereich des Absatzes wurde das Potenzial ebenfalls erkannt. Das Internet bietet zusehends die Möglichkeit des Online-Einkaufs, viele der im Web präsenten Unternehmen haben auf ihren Seiten Online-Shops eingerichtet. Derzeit handelt es sich bei den angebotenen Waren meistens noch um tatsächlich physisch existierende Artikel. Diese müssen natürlich auch bei elektronischer Bestellung netzunabhängig ausgeliefert werden; hier sind konventionelle Zahlungsverfahren wie Rechnung, Nachnahme oder Bankeinzug günstig einsetzbar. Das Internet dient dabei nur als komfortables Medium zur Bestellaufgabe. Die Möglichkeit, rein digitale Ware über das Internet zu bestellen und zu erhalten, ist derzeit noch eher selten. Vermutlich wird sich das aber schon in naher Zukunft ändern, denn es existieren sowohl ein umfangreiches potenzielles digitales Warenangebot als auch ein Markt für diese Waren. Gehandelt werden kann beispielsweise mit Information (z.b. Ergebnisse von Suchmaschinen, Lexikoneinträge,..), Online-Büchern, Software oder auch mit Musik (gerade hier gibt es durch MP3 neue Herausforderungen für die Musikbranche). Wenn die angeforderte Ware nur rein elektronisch zur Verfügung steht, sind herkömmliche Zahlungsverfahren nicht nur teuer (z.b. durch Nachnahmegebühr), sondern durch den Medienbruch auch umständlich und unbequem. Es sollte also insbesondere für diese Waren die Möglichkeit geben, nicht nur die Ware auf elektronischem Wege zu bestellen und zu erhalten, sondern auch elektronisch zu bezahlen. In den letzten Jahren wurde eine Vielzahl elektronischer Zahlungsverfahren entwickelt; viele befinden sich noch in der Probephase. Dabei gibt es unterschiedliche Ansätze, wie z.b. die sichere Übermittlung von Kreditkartendaten als auch die Entwicklung elektronischen Geldes. Anhand verschiedener Charakteristika lassen sich die Verfahren jedoch klassifizieren (s. Kapitel 3). Dabei wird auch deutlich, welche Verfahren sich für welche Einsatzgebiete besonders eignen bzw. in welchen Bereichen sie überhaupt einsetzbar sind.

215 13.2. ANFORDERUNGEN AN ELEKTRONISCHE ZAHLUNGSVERFAHREN Anforderungen an elektronische Zahlungsverfahren Elektronische Zahlungsverfahren müssen ähnlichen Anforderungen genügen wie konventionelle Verfahren. Die Hauptanforderungen sind: ffl Integrität ffl Anonymität ffl Authenzität ffl Bequemlichkeit Dabei handelt es sich bei den Begriffen Integrität, Anonymität und Authenzität um Sicherheitsanforderungen; Bequemlichkeit dagegen ist eine Anforderung von Kunde und Markt. Die wichtigste Anforderung ist Integrität: elektronisches Geld muss sicher sein vor Fälschung und Verfälschung. D.h. es muss zum einen unmöglich sein, Geld zu fälschen, zu kopieren oder auf andere Weise selbst herzustellen; zum anderen darf vorhandenes Geld nicht änderbar sein, da sonst der Wert geändert werden könnte. Der nächste Punkt ist Anonymität. Der Kunde soll nicht für jede Zahlung dem Händler seine Identität offenbaren müssen. Ebenso soll es niemand Anderem, insbesondere einer Bank, möglich sein, Kauf- oder Zahlungsvorgänge von Kunden zu protokollieren, und auf diese Weise Schlüsse über das Kaufverhalten zu ziehen. Dies ist aus Datenschutzgründen notwendig. Andererseits bietet die Anforderung der Anonymität natürlich eine geeignete Basis für Kriminalität, insbesondere für den Handel mit illegalen Waren sowie für Geldwäsche. Durch die Anforderung der Authenzität soll sichergestellt werden, dass niemand durch Vortäuschung einer anderen Identität über Geld verfügt, das einer anderen Person gehört. Auf diese Weise wird z.b. verhindert, dass jemand gestohlene Kreditkarteninformationen missbraucht. Um sich bei den Kunden und somit auf dem Markt durchzusetzen, muss ein Zahlungsverfahren bequem sein, d.h. es muss unkompliziert, einfach, durchschaubar und schnell sein. Erfüllt es diese Anforderung nicht, so ist es unwahrscheinlich, dass das Verfahren weitgehende Resonanz findet.

216 202 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET 13.3 Sicherheitstechnische Grundlagen Um die Sicherheitsanforderungen Integrität, Anonymität und Authenzität zu erfüllen, benutzen alle wichtigen Zahlungsverfahren kryptographische Verfahren. Deshalb soll hier auf die Grundlagen dieser Verfahren eingegangen werden. Angewendet werden üblicherweise die Konzepte der symmetrischen und asymmetrischen Verschlüsselung, der sicheren Hashfunktion sowie der digitalen Signatur Verschlüsselungsverfahren Das Grundprinzip der Verschlüsselung ist recht einfach. Ein Klartext m wird durch Anwendung einer Verschlüsselungsfunktion e mit einem Chiffrierschlüssel k e zu einem Chiffretext c verschlüsselt. Der Empfänger des Chiffretextes kann diesen nun durch die Entschlüsselungsfunktion d mit dem Dechiffrierschlüssel k d zum Klartext m entschlüsseln. Abbildung 13.1: Prinzip der Verschlüsselung. Quelle: [DL97] Man unterscheidet zwei Arten von Verschlüsselungsverfahren. Bei den sogenannten Secret Key-Verfahren (auch: symmetrische Verfahren) sind Chiffrier- und Dechiffrierschlüssel identisch, d.h. ein Text wird mit demselben Schlüssel ver- und entschlüsselt. Bei den Public Key-Verfahren (auch: asymmetrische Verfahren) sind Chiffrier- und Dechiffrierschlüssel verschieden, man benötigt also unterschiedliche Schlüssel zum Ver- und Entschlüsseln des Textes Secret Key-Verfahren (symmetrisch) Bei den Secret Key-Verfahren wird zum Codieren und Decodieren einer Nachricht derselbe Schlüssel verwendet, daher auch die Bezeichnung symmetrische Verschlüsselungsverfahren. Der Vorteil dieses Verfahrens liegt in der Effizienz, wodurch es insbesondere für längere Nachrichten interessant ist. Die Sicherheit der verschlüsselten Nachricht selbst hängt dabei maßgeblich von der Länge des verwendeten Schlüssels ab. Die absolute Geheimhaltung des Schlüssels ist zwingend notwendig.

217 13.3. SICHERHEITSTECHNISCHE GRUNDLAGEN 203 Größtes Problem der symmetrischen Verschlüsselung ist aber die Übertragung des Schlüssels selbst. Kann diese nicht über ein sicheres Medium stattfinden (z.b. ein persönliches Treffen), so muß dazu wieder ein unsicherer Kanal (z.b. das Internet) benutzt werden, wodurch der Schlüssel dann abgehört werden kann. Gelöst werden kann das Problem durch Verschlüsselung des Schlüssels selbst; dieses Verfahren findet z.b. bei einer Kombination von Secret Key- und Public Key-Verfahren Anwendung (s. Kap. 3.4). Ein zusätzliches Problem stellt die Anzahl der benötigten Schlüssel bei mehreren Kommunikationspartnern dar. Für jedes Kommunikationspaar wird ein Schlüssel benötigt; bei n Teilnehmern sind also insgesamt n 2 Schlüssel erforderlich. Das bekannteste symmetrische Verfahren ist DES (mit einer Schlüssellänge von 56 Bit), das heute sowohl in Hard- und Software als auch in Smartcards oft eingesetzt wird. Die Weiterentwicklung dieses Verfahrens ist Triple-DES mit einer Schlüssellänge von 112 Bit Public Key-Verfahren (asymmetrisch) Bei der Public Key-Verschlüsselung werden zwei verschiedene Schlüssel zum Ver- und Entschlüsseln einer Nachricht verwendet. Jeder Teilnehmer besitzt ein Schlüsselpaar bestehend aus einem öffentlichen Schlüssel (Public Key) und einem privaten Schlüssel (Private Key). Der private Schlüssel wird dabei vom Besitzer geheimgehalten, der öffentliche Schlüssel sollte veröffentlichtwerden, z.b. in einer öffentlichzugänglichen Datenbank. Will nun ein Sender A einem Empfänger B eine verschlüsselte Nachricht schicken, so benutzt er zum Codieren den öffentlichen Schlüssel von B. Die Nachricht kann dann nur von B mit dessen privatem Schlüssel decodiert werden. Bei diesem Verfahren entfällt die Übertragung eines geheimen Schlüssels über ein unsicheres Medium; zudem sollte es nicht möglich sein, aus dem öffentlichen Schlüssel einer Person dessen privaten Schlüssel abzuleiten. Ein weiterer Vorteil dieser Methode ist, dass es je Teilnehmer nur ein Schlüsselpaar gibt, d.h. die Gesamtanzahl der Schlüssel steigt linear mit der Anzahl der Teilnehmer. Zu den Nachteilen des Verfahrens gehört, dass die Schlüssel im Vergleich zu anderen Verfahren sehr groß sind. Außerdem sind Public Key-Verfahren bedeutend ineffizienter als Secret Key-Verfahren, weshalb sie oftmals nur zum Codieren des Schlüssels eines Secret Key-Verfahrens eingesetzt werden. Das wohl wichtigste Public Key-Verfahren ist RSA. Die Schlüssellänge beträgt hier üblicherweise 1024 Bit; privater und öffentlicher Schlüssel werden durch ein mathematisches Verfahren aus zwei sehr großen Primzahlen abgeleitet (jeweils mindestens 100 bis 200 Dezimalstellen). Die Sicherheit von RSA liegt darin, daß der private Schlüssel nicht ohne die Faktorisierung des Produktes der beiden Primzahlen aus dem öffentlichen Schlüssel abgeleitet werden kann, was als sehr aufwendig gilt. Eine Besonderheit von RSA ist es, daß eine Nachricht nicht nur mit dem öffentlichen Schlüssel codiert und mit dem privaten Schlüssel decodiert werden kann, sondern auch umgekehrt mit dem privaten Schlüssel codiert und mit dem Öffentlichen decodiert. Dies liegt in dem zugrunde liegenden mathematischen Verfahren begründet und findet Anwendung bei der digitalen Signatur (s. Kap. 3.5).

218 204 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET Kombination aus Secret- und Public Key-Verfahren Da im Allgemeinen die Verschlüsselung mit einem Secret Key-Verfahren effizienter ist als die mit einem Public Key-Verfahren und auf der anderen Seite die Verschlüsselung mit einem Public Key-Verfahren keinen unsicheren Schlüsselaustausch erfordert, liegt es nahe, eine Kombination beider Verfahren zu verwenden. Dabei wird die Nachricht mit einem Secret Key-Verfahren verschlüsselt, dann wird der verwendete Schlüssel mit einem Public Key-Verfahren codiert. Ein Protokoll, das diese Art der Verschlüsselung benutzt, ist SSL (Secure Socket Layer). Dort wird eine Kombination aus DES (mit einem zufällig gewähltem Schlüssel) und RSA angewendet. Abbildung 13.2: Kombination von DES und RSA. Quelle: [Sto97] Bei SSL handelt es sich um eine zusätzliche Protokollschicht zwischen TCP/IP und höheren Internetprotokollen wie HTTP, Telnet, Gopher usw. Durch diese Protokollschicht erfolgt die sichere Übertragung sonst ungeschützter Daten über das Internet. Für den Anwender ist die Verschlüsselung einer WWW-Seite mittels SSL durch die URL zu erkennen: sie beginnt mit " statt des üblichen " Außerdem ist das Schloßsymbol im Browser geschlossen. Angewendet wird SSL vor allem für die Übertragung kritischer Informationen wie Kontonummer, Kreditkarteninformationen, Adresse etc Sichere Hashfunktionen Eine sogenannte sichere Hashfunktion dient dazu, eine kryptographische Prüfsumme eines Dokuments zu erzeugen. Bei dieser Funktion handelt es sich um eine Einwegfunktion, also eine Funktion ohne Umkehrfunktion. Sie bildet das gesamte Dokument auf eine Prüfsumme fester Länge ab und erzeugt so einen digitalen Fingerabdrucks des Dokuments. Die Hashfunktion ist derart, dass jede Änderung des Dokuments die Prüfsumme ändert. Aus der Prüfsumme lassen sich jedoch keine Schlüsse über den Inhalt der Nachricht ziehen. Auf diese Art können sowohl unbeabsichtigte Verfälschungen als auch absichtliche Manipulationen des Dokuments erkannt werden, wodurch die Datenintegrität gesichert wird. Dazu erzeugt der Sender einer Nachricht mittels einer Hashfunktion die Prüfsumme der Nachricht und schickt beides an einen Empfänger. Dieser überprüft die Nachricht, indem er ebenfalls mit derselben Hashfunktion eine Prüfsumme erzeugt. Stimmen beide Prüfsummen überein, so stimmt die Nachricht mit hoher Wahrscheinlichkeit mit der ursprünglich Gesendeten überein.

219 13.3. SICHERHEITSTECHNISCHE GRUNDLAGEN 205 Häufig werden sowohl die Hashfunktion als auch die Prüfsumme selbst als Message Digest bezeichnet. Man unterscheidet starke und schwache Message Digests. Bei starken Message Digests ist es nicht möglich, mit angemessenem Aufwand zwei verschiedene Texte mit derselben Prüfsumme zu finden. Als schwache Message Digests gelten solche Hashfunktionen, bei denen es nicht mit angemessenem Aufwand möglich ist, zu einem gegebenem Text einen anderen mit derselben Prüfsumme zu finden Digitale Signatur Wie bereits angedeutet ist aufgrund der mathematischen Struktur der Verschlüsselung bei RSA die Verschlüsselung in beide Richtungen möglich. Das heisst, eine Nachricht kann auch mit dem privaten Schlüssel einer Person verschlüsselt und dann mit dem öffentlichen Schlüssel dieses Teilnehmers decodiert werden. Auf diese Weise lassen sich digitale Signaturen realisieren. Ein Teilnehmer A signiert eine Nachricht, indem er sie mit seinem privaten Schlüssel codiert; jede andere Person kann diese mit dem entsprechenden öffentlichen Schlüssel entschlüsseln und so sicher sein, dass die Nachricht wirklich von Teilnehmer A stammt. Durch dieses Verfahren wird Authenzität gewährleistet. Häufig wird als Dokument, das zwecks digitaler Unterschrift codiert wird, auch die Prüfsumme einer sicheren Hashfuntkion verwendet. So werden zugleich Authenzität und Integrität gesichert.

220 206 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET 13.4 Charakteristika von Zahlungsarten Um existierende Zahlungsverfahren im Internet zu analysieren, ist es notwendig, die Charakteristika, die Zahlungsarten aufweisen können, näher zu untersuchen. Auf diese Art können Zahlungsverfahren klassifiziert werden; aufgrund dieser Klassifikation lässt sich dann schließen, welche Verfahren für ein bestimmtes Anwendungsgebiet am besten geeignet sind. Hier werden die Charakteristika Zeitpunkt der Zahlung, Höhe der Zahlung und Art der Zahlung untersucht Zeitpunkt der Zahlung Jede Zahlungsart - nicht nur Zahlungsverfahren im Internet - lässt sich nach dem Zeitpunkt der Zahlung klassifizieren. Unterschieden wird zwischen Kreditverfahren und Debitverfahren. Bei einem Kreditverfahren erfolgt die Lieferung der Ware bzw. das Erbringen einer Dienstleistung vor der Bezahlung. Wie durch den Namen angedeutet, gewährt der Händler dem Kunden dabei einen Kredit, welcher zuzüglich eventueller Kreditgebühren zu begleichen ist. Dadurch liegt ein höheres Risiko beim Händler. Durch die Gebühren sind Kreditverfahren für geringe Zahlungsbeträge oft unrentabel. Typisches Beispiel für ein Kreditverfahren ist die Bezahlung per Rechnung, z.b. eine Telefonrechnung. Bei den Debit- oder guthabenbasierten Verfahren ist es umgekehrt: der Kunde besitzt ein Guthabenkonto bei einem Händler. Dieses Konto kann er auffüllen und das Guthaben stückweise verbrauchen. Bei dieser Art der händlerspezifischen guthabenbasierten Verfahren sind die entstehenden Zusatzkosten durch Gebühren etc. sehr gering bzw. entfallen völlig, da jeder Händler seine Kundenkonten ohne Hilfe einer Bank selbst verwaltet. Dadurch sind diese Verfahren insbesondere für geringe Beträge interessant. Beispiele für händlerspezifische Debitverfahren sind die Bezahlung per Vorkasse und eine Telefonkarte. Nachteil dieses Verfahrens ist jedoch, dass der Kunde an einen bestimmten Händler gebunden ist. Dieser Nachteil kann durch händlerunabhängige Systeme ausgeräumt werden. Zu den händlerunabhängigen Debitverfahren gehört z.b. elektronisches Geld, das üblicherweise durch den Kunden selbst in einer elektronischen Geldbörse verwaltet wird und bei mehreren Händlern als Zahlungsmittel akzeptiert wird. Darauf wird jedoch in Kapitel 4.3 näher eingegangen Art der Zahlung Die Art der Zahlung beinhaltet, wie der Händler an sein Geld oder die Informationen, die ihm das Geld liefern, kommt. Mögliche Zahlungsarten sind Offline-Zahlung, scheckbasierte Verfahren, kreditkartenbasierte Verfahren sowie elektronisches Bargeld.

221 13.4. CHARAKTERISTIKA VON ZAHLUNGSARTEN 207 Durch die Art der Zahlung wird schon ein Teil der durch die Zahlung anfallenden Zusatzkosten determiniert, ebenfalls lassen sich abhängig davon auch erste Schlüsse über die Sicherheit ziehen (so ist z.b. eine Offline-Zahlung niemals anonym). Die Offline-Zahlung umfasst die konventionellen Zahlungsarten wie Rechnung, Nachnahme und Bankeinzug. Die Zahlung erfolgt also immer netzunabhängig, was im Falle einer digitalen Warenlieferung einen Medienbruch darstellt. Bei einer Offline-Zahlung geht die Anonymität des Kunden zwangsweise verloren. Teilweise entstehen zusätzliche Kosten, z.b. eine Nachnahmegebühr. Insgesamt ist die Offline-Zahlung für digitale Ware extrem ungeeignet, deshalb spielt sie auch in der weiteren Betrachtung keine Rolle mehr. Bei scheckbasierten Zahlungsverfahren müssen Kunde und Händler ein Konto bei einer Bank oder einem Dienst besitzen. Transaktionen zwischen den Konten können mittels verschlüsselter Nachrichten getätigt werden. Die Transaktionen sind jedoch nicht anonym. Für elektronische Ware sind scheckbasierte Zahlungsverfahren wegen der entstehenden Kontoführungskosten und der fehlenden Anonymität nur bedingt geeignet. Die derzeit weitest verbreiteten elektronische Zahlungsverfahren sind die kreditkartenbasierten Verfahren. Dabei werden die Kreditkarteninformationen des Kunden an den Händler übermittelt. Dies setzt natürlich voraus, das der Kunde über eine Kreditkarte verfügt. Der Händler kann die erhaltenen Daten beim entsprechenden Kreditinstitut auf ihre Gültigkeit prüfen lassen. Die Kreditkartendaten sollten natürlich verschlüsselt übermittelt werden; um dem Missbrauch gestohlener Daten vorzubeugen, werden die Daten häufig mit einer digitalen Signatur versehen. Die Anonymität des Kunden gegenüber dem Händler kann bei den kreditkartenbasierten Zahlungsverfahren erreicht werden, wenn ein TrustCenter als Mittler zwischen Kunde und Händler dient. Der Kunde übermittelt seine Daten dann an dieses, und das TrustCenter übernimmt die Zahlung beim Händler. Allerdings ist auch auf diese Weise, wie bei allen Zahlungen durch Kreditkarten, eine vollständige Anonymität nicht zu erreichen. Bei den kreditkartenbasierten Verfahren entstehen zusätzliche Kosten durch die Gebühren, die die Kreditunternehmen fordern, deshalb sind diese Verfahren vor allem im Bereich der Macro-Payments interessant. Als Beispiel für ein kreditkartenbasiertes Verfahren wird in Kapitel 5 das SET-Protokoll vorgestellt. Elektronisches Geld stellt ein händlerunabhängiges guthabenbasiertes Zahlungsverfahren dar. Dabei werden digitale Dokumente erzeugt, die einen betimmten Geldbetrag repräsentieren. Diese Dokumente können wie echtes Geld weitergereicht werden und auch wieder in echtes Geld eingewechselt werden. Einen wichtigen Faktor bildet dabei die Anonymität des Benutzers. Diese soll möglichst bewahrt werden; das elektronische Geld soll gültig sein, ohne dass man überprüfen muss und kann, von wem es kommt. Da es sich bei elektronischem Geld um digitale Dokumente handelt, wären diese ohne zusätzlichen Schutz natürlich leicht zu fälschen, verfälschen und reproduzieren. Dies soll jedoch durch kryptographische Schutzmaßnahmen verhindert werden. So dienen Prüfsummen und digitale Signaturen gegen Verfälschungen; Echtheitszertifikate sollen Fälschungen verhindern. Um absichtliche oder unabsichtliche Mehrfachausgaben zu verhindern kann

222 208 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET darüber Buch geführt werden, welche Münzen bereits verwendet wurden. Zum Schutz vor Diebstahl kann zusätzliche Hardware verwendet werden, auf der die digitalen Münzen gespeichert sind, z.b. Smartcards. Die Kosten, die bei Verwendung von elektronischem Bargeld entstehen, sind äußerst gering. Dadurch sind diese Verfahren auch im Bereich der Small- und Micro-Payments einsetzbar. In Kapitel 5 werden das Ecash-Verfahren und das MilliCent-Verfahren, welches insbesondere für Kleinstbeträge optimiert ist, vorgestellt Höhe der Zahlung Insbesondere für Zahlungsverfahren im Internet ist die Höhe einer Zahlung von besonderer Bedeutung, denn daraus lässt sich schließen, welche Zahlungsverfahren für eine Zahlung überhaupt rentabel sind und somit in Frage kommen. Dabei sind sowohl die Fixkosten eines Verfahrens (z.b. durch Gebühren) als auch die Kosten, die durch Einhaltung von Sicherheitsanforderungen entstehen (Online-Validierung, Verschlüsselung etc.) zu beachten. Im Allgemeinen wird davon ausgegangen, dass mit abnehmenden Beträgen auch die Sicherheitsanforderungen sinken, denn zusätzliche Sicherheit ist immer mit zusätzlichen Kosten verbunden. Unterschieden wird zwischen Macro-Payments, Small Payments und Micro-Payments. Zu den Macro-Payments gehören alle Zahlungen mit Beträgen ab etwa 10,- DM. Für diese Zahlungen lassen sich sowohl scheckbasierte als auch kreditkartenbasierte Verfahren anwenden (s. Kapitel 4.3). Die Sicherheitsanforderungen sind dabei sehr hoch. Als Small Payments bezeichnet man Beträge zwischen 50 Pfennigen und 20,- DM; als Zahlungmittel dient üblicherweise elektronisches Bargeld. Unter Micro-Payments versteht man Zahlungen im Wert von Bruchteilen von Pfennigen bis zu 1,- DM (denkbar z.b. für Webseiten, Lexikoneinträge etc.). Auch hier werden elektronisches Bargeld bzw. Abwandlungen davon verwendet. Um auch solche geringen Zahlungen rentabel zu machen, ist es notwendig die Transaktionskosten so gering wie möglich zu halten. Dazu wird von sehr geringen Sicherheitsanforderungen ausgegangen. Dennoch ist es Ziel dieser Verfahren, jeden Betrug teurer zu machen als den Wert der abgesicherten Zahlungen.

223 13.5. VORSTELLUNG EINZELNER ZAHLUNGSVERFAHREN Vorstellung einzelner Zahlungsverfahren Nachdem im letzten Kapitel die hinter elektronischen Zahlungsverfahren stehenden Ideen, Ansätze und Prinzipien erläutert wurden, sollen jetzt einige ausgewählte Zahlungsverfahren vorgestellt werden. Dabei handelt es sich um das SET-Protokoll als kreditkartenbasiertes Verfahren für Macro-Payments, das Ecash-Verfahren, das auf elektronischen Münzen basiert und sich für den Bereich der Small Payments anbietet, und das für Kleinstbeträge optimierte MilliCent-Verfahren. Diese Auswahl ist jedoch nur exemplarisch, es existieren weitere Verfahren, die in den meisten Fällen den hier dargestellten jedoch recht ähnlich sind und auf denselben Prinzipien beruhen SET (Secure Electronic Transaction) Bei SET handelt es sich sich um ein Protokoll zur sicheren Übertragung von Kreditkarteninformationen über das Internet. Eine Realisierung des Protokolls ist im CyberCash- Verfahren zu finden, es existieren inzwischen aber auch viele weitere Umsetzungen. Entwickelt wurde SET u.a. von den Kreditkartenunternehmen VISA und Mastercard, sowie von Microsoft und Netscape. Dadurch ist einer breiten Anwendung des Protokolls durch die weite Verbreitung der Web-Browser von Microsoft und Netscape der Weg geebnet. Der Ablauf einer auf dem SET-Protokoll basierenden Transaktion ist Folgender: 1. Der Kunde wählt die Produkte oder Leistungen, die er erhalten möchte, über das Internet aus. 2. Er gibt seine Kreditkarten-Informationen online in ein Formular ein. Dann werden die Bestell- und Kreditkartendaten getrennt voneinander verschlüsselt und digital signiert. Zusätzlich werden beide Datenpakete mit der ebenfalls verschlüsselten Prüfsumme der jeweils anderen Daten versehen. Dadurch kann überprüft werden, ob Bestell- und Zahlungsdaten zum gleichen Bestellvorgang gehören oder ob sie manipuliert wurden. Anschließend werden die Daten über das Internet an den Händler geschickt. 3. Der Händler kann nur die Bestelldaten, nicht aber die Zahlungsdaten entschlüsseln. Er fügt beiden Datenpaketen seine digitale Signatur hinzu und schickt sie an den SET-Server der Bank. 4. Der Server der Bank kann nur die Zahlungsinformationen, jedoch nicht die Bestelldaten entschlüsseln. Er führt eine Online-Verifikation durch und führt bei positiver Verifikation die Transaktion vom Kreditkartenkonto des Kunden durch. 5. Der Händler erhält vom SET-Server die positive oder negative Mitteilung über die Transaktion. 6. Bei positiver Nachricht kann der Händler die Ware ausliefern bzw. den Download ermöglichen.

224 210 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET Im SET-Protokoll erfolgt die Übermittlung der Bestell- und Zahlungsdaten verschlüsselt und mit Prüfsumme, dadurch wird die Integrität dieser Daten sichergestellt. Durch die getrennte Verschlüsselung, die die Zahlungsdaten vor dem Händler und die Bestelldaten vor der Bank verbirgt, wird die bei kreditkartenbasierten Verfahren größtmögliche Anonymität erreicht. Dennoch bilden Bestell- und Zahlungsdaten durch die Prüfsumme eine eindeutige Einheit. Die Authentifikation aller an der Transaktion beteiligter Parteien wird durch eine digitale Signatur realisiert, dadurch wird z.b. der Missbrauch gestohlener Kreditkartendaten verhindert. Ein weiterer Vorteil des SET-Protokolls liegt in der breiten Unterstützung durch die Industrie in den relevanten Bereichen, also Banken, Kreditkartenunternehmen und Softwarehersteller. Ferner definiert SET nur ein von den zu übertragenden Daten unabhängiges Protokoll, es ist also nicht nur für Kreditkartendaten, sondern auch z.b. für Bankverbindungsdaten einsetzbar. Die Verwendung des SET-Protokolls in konkreten Zahlungsverfahren ist ohne Lizensierungsgebühren möglich. Dadurch dürfte SET einen weiteren Vorteil auf dem Weg zum Standard besitzen. Deutlicher Nachteil des Verfahrens - sofern es zur Übertragung von Kreditkartendaten benutzt wird - sind jedoch die erheblichen zusätzlichen Transaktionskosten, die bei der Verwendung von Kreditkarten entstehen. Um wirtschaftlich zu sein, wird daher von einem Mindestbetrag von etwa 20 DM ausgegangen. Für eine Verwendung im Bereich der Smalloder gar Micro-Payments ist SET daher ungeeignet. Abbildung 13.3: Übermittlung und Verifikation der Zahlungsdaten über Cybercash. Quelle:[Sto97] Eine konkrete Implementierung des SET-Protokolls bietet das bereits erwähnte Verfahren von Cybercash, genauer gesagt war das Cybercash-Verfahren sogar die Grundlage

225 13.5. VORSTELLUNG EINZELNER ZAHLUNGSVERFAHREN 211 von SET. Unterschiede zum SET-Protokoll gibt es nur wenige. Der Wichtigste ist, dass im Gegensatz zu SET die Übertragung von Kreditkarten- und Bestelldaten unabhängig voneinander erfolgt. Außerdem gibt der Kunde seine Kreditkartendaten nicht online ein, sondern einmalig in eine Wallet-Anwendung. Ansonsten sind alle wichtigen Merkmale von SET wie die Teilanonymität gegenüber Händler bzw. Bank, die eindeutige Kennzeichnung der Datenpakete sowie die Online-Verifikation vorhanden. Die Verschlüsselung der Daten und deren Versand vom Kunden zum Händler erfolgt über eine Wallet-Software, die derzeit nur für Microsoft Windows (3.1, 95 und NT) verfügbar ist. Auf Seite des Händlers muss ein Programmpaket names " Cash Register installiert sein, das für MS Windows, Solaris/SPARC sowie Linux erhältlich ist. In Abbildung 3 ist der prinzipielle Ablauf einer Transaktion durch Cybercash dargestellt Ecash Das Ecash-Verfahren wurde von der Firma DigiCash entwickelt und gehört zu den münzbasierten Systemen des elektronischen Bargelds. Der Anwender bekommt digitale Münzen, für die er - wie für echtes Geld - selbst verantwortlich ist, d.h. er muss sich selbst vor Diebstahl und Verlust schützen. Sein elektronisches Geld verwaltet der Benutzer über die sogenannte Cyberwallet-Software, die er auf seinem Rechner installiert. Über die Cyberwallet ist jeder in der Lage, sowohl elektronisches Geld zu verschicken als auch zu erhalten, ebenso können die Münzen wieder in reales Geld eingetauscht werden. Somit können Münzen auch zwischen Privatanwendern transferiert werden, ebenso kann jede Privatperson als Händler agieren. Die Software ist derzeit allerdings nur für MS Windows verfügbar. Zu den wichtigsten Anforderungen an elektronisches Bargeld gehören die Fälschungssicherheit bei möglichst gleichzeitiger Anonymität der Kunden. Dies wird bei Ecash durch sogenannte blinde Unterschriften realisiert. Die Münzen sind dabei zwar mit Seriennummern versehen; die ausgebende Bank kennt jedoch nicht die Seriennummern der ausgegebenen Münzen. Um dennoch eine Online-Verifikation zu ermöglichen versieht die Bank die Münzen mit Zertifikaten, anhand derer sie die Echtheit und Gültigkeit einer Münze erkennen und bestätigen kann. Somit ist es der Bank nicht möglich, den Verlauf einer Münze zu verfolgen. Dadurch kann der Kunde sowohl gegenüber Händler als auch Bank anonym bleiben. Die kritischen Vorgänge dieses Verfahrens, also das Abheben digitaler Münzen und der Zahlungsvorgang, sollen im Folgenden näher erläutert werden, wobei mit dem Abheben von Münzen begonnen wird. Um gültige digitale Münzen zu erhalten, generiert der Kunde zuerst auf seinem PC Münzrohlinge. Dabei kann der Wert der Münze selbst gewählt werden, die Seriennummer wird zufällig erzeugt, wobei aufgrund der Länge identische Seriennummern sehr unwahrscheinlich sind. Nun multipliziert der Kunde die Seriennummer mit einer nur ihm bekannten Zahl und verschlüsselt anschließend die gesamte Münze mit dem öffentlichen Schlüssel der Bank (mittels modifiziertem RSA-Algorithmus), fügt seine digitale Signatur hinzu und schickt das Paket an die Bank. Diese kann zwar die Münze und deren Betrag entschlüsseln und kann aufgrund der digitalen Signatur davon ausgehen, dass die Münze wirklich vom Kunden stammt, kennt jedoch nicht die Seriennummer. Die Bank bucht

226 212 KAPITEL 13. ELEKTRONISCHER ZAHLUNGSVERKEHR IM INTERNET Abbildung 13.4: Erzeugung digitaler Münzen bei Ecash. Quelle: [Sto97] den Betrag vom Konto des Kunden ab, fügt der Münze ein digitales Zertifikat hinzu und schickt sie wieder verschlüsselt an den Kunden. Dieser entschlüsselt die Münze und die Seriennummer, wobei das Zertifikat erhalten bleibt. Damit ist die Münze gültig und einsatzbereit. Der ganze Vorgang der Münzgenerierung und Zertifizierung wird automatisch durch die Cyberwallet durchgeführt. Der Bestell- und Zahlungsvorgang läuft folgendermaßen ab: Der Kunde wählt die Produkte, die er bestellen möchte, aus und schickt seine Bestellung über das Internet an den Händler. Durch ein CGI-Skript wird dessen Cyberwallet angewiesen, eine Zahlungsaufforderung an die Cyberwallet des Kunden zu schicken. Der Kunde wird über die Aufforderung informiert und kann diese nun bestätigen oder ablehnen. Im Falle einer Bestätigung wird der entsprechende Betrag in Form digitaler Münzen von der Cyberwallet des Kunden zu der Cyberwallet des Händlers transferiert, dabei wird wieder das RSA-Protokoll verwendet. Dabei ist es wichtig, dass die Münzen in passender Form vorhanden sind, da keine Rückgaben durchgeführt werden und der Vorgang in diesem Fall abbricht. Wurden die Münzen zur Cyberwallet des Händlers transferiert, so werden sie nun zur Online-Verifikation zum Bankserver geschickt. Dieser überprüft Echtheit, Gültigkeit und ob die Münzen bereits verwendet wurden (also in reales Geld zurückgetauscht wurden). Das Ergebnis wird dem Händler mitgeteilt. Dieser veranlasst daraufhin die Warenauslieferung / Downloadmöglichkeit etc. und benachrichtigt den Kunden über den erfolgreichen Zahlungsvorgang. Das Ecash-Verfahren realisiert die prinzipiellen Sicherheitsanforderungen an elektronisches Geld sehr gut. Der Kunde kann aufgrund der Online-Verifikation der Münzen gegenüber dem Händler anonym bleiben; ebenso ist es der Bank nicht möglich, Zahlungsvorgänge zu protokollieren, da sie lediglich Informationen darüber besitzt, wieviel elektronisches Geld jemand angefordert hat, jedoch nichts über dessen Verbleib herausfinden kann. Durch die Online-Verifikaton ist ebenfalls für den Händler das Risiko, ungültige