Bibliotheksdienste fr ein Studierendenportal an der Uni Oldenburg

PG.Portal
Bibliotheksdienste für ein
Studierendenportal an der Uni Oldenburg
Endbericht
18. April 2006
Teilnehmer
Timo Albrecht B.Sc., Timo Bernack B.Sc., Jan-Christian Denker,
Alexander Duscheleit, Christoph Jobelius, Dipl.-Inform. (FH) Stephan Kraft,
Bo Li, Michael Riehemann, Hermann Schulte-Borchers, Miriam Wolff,
Ahmed Youssefi und Ling Zou
Betreuer
Apl. Prof. Dr. Jürgen Sauer
Dr.-Ing. Frank Oldenettel
Dipl.-Inf. Nico Müller
Dipl.-Inf. (FH) Sabine Müller

Zusammenfassung
Dieser Endbericht beschreibt die Entwicklung der Projektgruppe Ein Studierendenportal
für die Uni Oldenburg der Abteilung Praktische Informatik an der Carl von Ossietzky
Universität Oldenburg. Während des einjährigen Projekts wurde für ein neues
i 3 sic-Studierendenportal der Universität Oldenburg ein auf das Oldenburger Regionales
Bibliotheks- und Informationssystem (ORBIS) und ausgewählte externe digitale Bibliotheken
zugeschnittener, auf Portlets basierender Bibliotheksdienst neu entwickelt und in
das Portal namens Liferay integriert. Dieser Dienst soll jedem Benutzer aus dem Portal
heraus eine bequeme, individualisierbare Recherche im Bestand lokaler und verschiedener
digitaler Bibliotheken ermöglichen.
Der vorliegende Bericht beinhaltet neben allen Seminararbeiten und der Anforderungsde-
nition umfangreiche Informationen zum Entwurf und der anschlieÿenden Implementierung.
Abstract
This report represents the development of the project group A students' portal for the
University of Oldenburg at the Practical Computer Science Group of the Carl von Ossietzky
University of Oldenburg. During this one year project a library service was developed
for a new i 3 sic students' portal of the University of Oldenburg. It is tailored to
the Oldenburger Regionales Bibliotheks- und Informationssystem (ORBIS) as well as
to hand-picked external digital libraries, furthermore based on portlets and integrated in
the portal called Liferay. This service enables every user a comfortable, individualizable
search within the stock of local and various digital libraries.
The present report contains, besides all our student research projects and our requirement
denition, extensive information on our draft and the subsequent implementation.

Inhaltsverzeichnis
1 Einleitung 13
1.1 Die Projektgruppe PG.Portal . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Überblick über den Endbericht . . . . . . . . . . . . . . . . . . . . . . . . 14
I Seminarausarbeitungen 17
2 Was ist ein Web-Projekt 19
2.1 Was ist ein Webprojekt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Wie unterscheiden sich Webprojekte voneinander? . . . . . . . . . . . . . . 19
2.3 Wer bestimmt in einem Webprojekt? . . . . . . . . . . . . . . . . . . . . . 20
2.4 Was ist zu tun? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Wer ist an einem Webprojekt beteiligt? . . . . . . . . . . . . . . . . . . . . 24
2.6 Was macht den Erfolg aus? . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Was macht die Kosten aus? . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Planung von Web-Projekten 29
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Allgemeine Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Strukturelle Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Wie genau sind die Kosten planbar . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Schätzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Das Ergebnis einer Schätzung . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Erstellen einer Schätzung . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Erfahrungswerte zum Vergleichen . . . . . . . . . . . . . . . . . . . 33
3.3.4 Typische Schätzfehler . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Allgemeine Einführung zu Schätzmethoden . . . . . . . . . . . . . . . . . . 34
3.4.1 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 Wahl der Schätzmethoden . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Schätzung im Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3

Inhaltsverzeichnis
3.5.1 Leitung der Schätzung im Team . . . . . . . . . . . . . . . . . . . . 35
3.5.2 Anforderungen an der Projektleitung . . . . . . . . . . . . . . . . . 36
3.5.3 Teamentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.4 Mögliche Gestaltung eines Teamtres . . . . . . . . . . . . . . . . . 37
3.6 Projektplan und Mitarbeitereinsatz . . . . . . . . . . . . . . . . . . . . . . 38
3.6.1 Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.2 Mitarbeitereinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 Iteratives Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Softwarearchitektur und Konzeption der Anwendungsschicht 42
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Softwarearchitektur und Komponenten . . . . . . . . . . . . . . . . . . . . 42
4.3 Konzepte und Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 J2EE Multi-Schichten-Architektur . . . . . . . . . . . . . . . . . . . 43
4.3.2 Technologien der Anwendungsschicht . . . . . . . . . . . . . . . . . 43
4.4 Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Session-Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2 Data Transfer Objects . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Entwurf und Implementierung von Websystemen 51
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Web Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Entwurf von Web-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1 Modellgetriebene Top-Down-Entwicklung . . . . . . . . . . . . . . . 53
5.3.2 Technologiegetriebene Bottom-Up-Entwicklung . . . . . . . . . . . 56
5.3.3 Strategien zur Architekturbildung . . . . . . . . . . . . . . . . . . . 58
5.4 Technologien und Standards der Implementierung . . . . . . . . . . . . . . 59
5.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Einführung in Portale und Portlets 62
6.1 Was sind Portale und warum nutzt man sie? . . . . . . . . . . . . . . . . . 62
6.1.1 Historisches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1.2 Portale sind wie ein Einkaufszentrum... . . . . . . . . . . . . . . . . 62
6.1.3 Was macht Portale aus? . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.4 Theoretisches Konzept . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Technische und ökonomische Vorteile von Portalen . . . . . . . . . . . . . . 64
6.3 Möglichkeiten von und in Portalen . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Was ist bei der Entwicklung von Portalen zu beachten? . . . . . . . . . . . 69
6.5 Was sind Portlets? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4

Inhaltsverzeichnis
6.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7 Java Portlet API JSR168 71
7.1 Portlet API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1.1 Container Contract und Lifecycle . . . . . . . . . . . . . . . . . . . 72
7.1.2 Window-State und Portlet-Mode . . . . . . . . . . . . . . . . . . . 73
7.1.3 Die Verwaltung von Portlet-Preferences . . . . . . . . . . . . . . . . 74
7.1.4 Benutzerinformationen . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.1.5 Packaging und Deployment . . . . . . . . . . . . . . . . . . . . . . 75
7.1.6 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1.7 JSP Tags zur Untersttzung bei der Portlet Entwicklung . . . . . . . 77
7.2 Web Service for Remote Portlets (WSRP) . . . . . . . . . . . . . . . . . . 78
8 Die Portal-Plattform Liferay 80
8.1 Was ist Liferay? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2.1 Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2.2 Personalisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.2.3 CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2.4 Single-Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.2.5 Einsatz von Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2.6 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2.7 verschiedene Sprachmodule . . . . . . . . . . . . . . . . . . . . . . . 84
8.2.8 Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2.9 Benutzergruppen und Rechtemanagement . . . . . . . . . . . . . . 85
8.3 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.4 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.4.1 Traditioneller Web-zugri . . . . . . . . . . . . . . . . . . . . . . 87
8.4.2 Liferay als Web-Service-Provider . . . . . . . . . . . . . . . . . . . 88
8.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9 Einführung in digitale Bibliotheken 89
9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.2 Digitale Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9.2.1 Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.2.2 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.2.3 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.2.4 Grundlegende Konzepte . . . . . . . . . . . . . . . . . . . . . . . . 94
9.3 Katalogisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5

Inhaltsverzeichnis
10 Aufgaben und Formen digitaler Bibliotheken 98
10.1 Probleme konventioneller Bibliotheken . . . . . . . . . . . . . . . . . . . . 98
10.2 Aufgaben einer digitale Bibliothek . . . . . . . . . . . . . . . . . . . . . . . 99
10.2.1 Sicht heutiger Bibliotheksnutzer . . . . . . . . . . . . . . . . . . . . 99
10.2.2 Sicht der wissenschaftlichen Forschung . . . . . . . . . . . . . . . . 100
10.2.3 Marktwirtschaftliche Sicht . . . . . . . . . . . . . . . . . . . . . . . 100
10.3 Produkte einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . . . . . 101
10.4 Dienstleistungen einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . 102
10.5 Organisationsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
10.6 Erscheinungsform als Web-Portal . . . . . . . . . . . . . . . . . . . . . . . 105
10.7 Eine mögliche technische Realisierung . . . . . . . . . . . . . . . . . . . . . 106
10.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
11 Verteilte und förderierte digitale Bibliotheken 110
11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
11.1.1 Digital Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
11.1.2 Verteilte bzw. föderierte digitale Bibliotheken . . . . . . . . . . . . 110
11.2 Vorgehensweisen zur Föderation von digitalen Bibliotheken . . . . . . . . . 111
11.3 Prinzipieller Ansatz zur Föderation digitaler Bibliotheken . . . . . . . . . . 111
11.3.1 5-Ebenen-Schema-Architektur . . . . . . . . . . . . . . . . . . . . . 112
11.3.2 Mediator-Wrapper-Prinzip . . . . . . . . . . . . . . . . . . . . . . . 113
11.4 Verschiedene Architekturansätze . . . . . . . . . . . . . . . . . . . . . . . . 114
11.4.1 InfoBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.4.2 eVerlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.4.3 OMNIS/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.4.4 BlueView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.4.5 DAFFODIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.5 Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12 Metadaten 122
12.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
12.2 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
12.2.1 Administrative Metadaten . . . . . . . . . . . . . . . . . . . . . . . 123
12.2.2 Deskriptive Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.2.3 Erhaltungsdienliche Metadaten . . . . . . . . . . . . . . . . . . . . 123
12.2.4 Technische Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.2.5 Nutzungsrelevante Metadaten . . . . . . . . . . . . . . . . . . . . . 124
12.3 Bibliotheksmetadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
12.4 Generierung von Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . 124
12.4.1 Experten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6

Inhaltsverzeichnis
12.4.2 Automatische Generierung . . . . . . . . . . . . . . . . . . . . . . . 125
12.5 Zweck von Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
12.6 Speicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
12.7 Fragen/Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
12.8 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
12.8.1 MARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
12.8.2 MAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
12.8.3 Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
12.8.4 MABxml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13 Metadatenstandards 130
13.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.2 Metadatenstandards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.2.1 Dublin Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.2.2 MARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.2.3 MARCXML und MODS . . . . . . . . . . . . . . . . . . . . . . . . 133
13.2.4 EAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.2.5 METS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.2.6 OAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
13.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.4 Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.4.1 METS Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
II Ergebnisdokumente der Softwareentwicklung 141
14 Bewertung von bestehenden Bibliotheksdiensten 143
14.1 Standardfunktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14.1.1 Ausleihe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14.1.2 Verlängerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14.1.3 Vorbestellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
14.1.4 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
14.1.5 Online-Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
14.1.6 Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
14.2 Strukturdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
14.2.1 Mahnungsverwaltung / Benachrichtigungsfunktion . . . . . . . . . . 147
14.2.2 Fernleihe (Vorbereitung) . . . . . . . . . . . . . . . . . . . . . . . . 147
14.2.3 Logische und räumliche Trennung von eigenen und fremden Inhalten 148
14.2.4 Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
14.3 Suchfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7

Inhaltsverzeichnis
14.3.1 Explorative Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
14.3.2 Suchmaske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.3.3 Websuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.4 Suchraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.4.1 Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
14.4.2 Lokal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
14.4.3 Suchkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
14.5 Medientyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
14.5.1 Formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
14.5.2 Inhaltlich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
14.6 Suchmaske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.6.1 Nutzung aller möglichen Suchkriterien . . . . . . . . . . . . . . . . 153
14.6.2 Nutzerklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.6.3 Suchassistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.6.4 Auswahl des Suchraums . . . . . . . . . . . . . . . . . . . . . . . . 154
14.6.5 Auswahl der Medientypen . . . . . . . . . . . . . . . . . . . . . . . 154
14.7 Ergebnispräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.7.1 Sortierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.7.2 Detaillierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
14.7.3 Bereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
15 Anforderungsdenition 157
15.1 Ausgangssituation, Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . 157
15.2 Systemeinsatz und Zielumgebung . . . . . . . . . . . . . . . . . . . . . . . 158
15.3 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 158
15.3.1 Benutzerklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
15.3.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
15.3.3 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
15.4 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 173
15.5 Benutzungsoberäche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
15.5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
15.5.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
15.5.3 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
15.5.4 Ergebnisausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
15.5.5 Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
15.5.6 mögliche Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . 181
15.6 Fehlerverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
15.7 Dokumentationsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 182
15.8 Akzeptanzkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
16 Entwurf 184
8

Inhaltsverzeichnis
16.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
16.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
16.2.1 Technologiewahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
16.2.2 Umzusetzende Anwendungs-Architektur . . . . . . . . . . . . . . . 188
16.3 Suchlogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
16.3.1 Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
16.3.2 Technologien und Modelle . . . . . . . . . . . . . . . . . . . . . . . 196
16.3.3 Klassenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 198
16.3.4 Dynamikbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 200
16.4 Mediator / Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
16.4.1 Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
16.4.2 Die verschiedenen Quellen . . . . . . . . . . . . . . . . . . . . . . . 201
16.4.3 Entwicklungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . 202
16.4.4 Technologien und Modelle . . . . . . . . . . . . . . . . . . . . . . . 202
16.4.5 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.5 Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.5.1 Technologien und Modelle . . . . . . . . . . . . . . . . . . . . . . . 209
16.5.2 Klassenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.5.3 Dynamikbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . 211
16.6 Benutzungsoberäche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
16.6.1 Client-seitige Darstellung . . . . . . . . . . . . . . . . . . . . . . . . 218
16.6.2 Portletaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
16.6.3 JSP-Beschreibungen (Server-seitige Darstellung) . . . . . . . . . . . 227
16.7 Datenbankmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
16.7.1 UserAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
16.7.2 OAI-Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
16.8 Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
16.8.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
16.8.2 Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
16.8.3 Testgegenstand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
16.8.4 Testmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
17 Implementierung 234
17.1 Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
17.1.1 Das Package org.pgportal.ejb.dto . . . . . . . . . . . . . . . . . 235
17.1.2 Das Package org.pgportal.ejb.mediator . . . . . . . . . . . . . . 241
17.1.3 Das Package org.pgportal.ejb.search . . . . . . . . . . . . . . . 241
17.1.4 Das Package org.pgportal.ejb.wrapper . . . . . . . . . . . . . . 241
17.1.5 Das Package org.pgportal.ejb.userAccount . . . . . . . . . . . . 241
17.1.6 Das Package org.pgportal.ejb.util . . . . . . . . . . . . . . . . 241
17.2 Suchlogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
9

Inhaltsverzeichnis
17.2.1 Methoden zur Suche und Sortierung . . . . . . . . . . . . . . . . . . 242
17.2.2 Methoden zur Filterung und Datenbereinigung . . . . . . . . . . . . 242
17.2.3 Methoden zur Relevanzbestimmung . . . . . . . . . . . . . . . . . . 243
17.2.4 Methoden zur Speicherung der Such-Chronik . . . . . . . . . . . . . 244
17.2.5 EJB-spezische Methoden . . . . . . . . . . . . . . . . . . . . . . . 245
17.2.6 Klassenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 245
17.3 Mediator / Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
17.3.1 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
17.3.2 Methoden des Mediators . . . . . . . . . . . . . . . . . . . . . . . . 247
17.3.3 Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
17.3.4 SRU-Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
17.3.5 OAI-Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
17.4 Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
17.5 Benutzungsoberäche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
17.6 Erläuterungen zum Testverlauf . . . . . . . . . . . . . . . . . . . . . . . . 261
18 Handbuch 264
18.1 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
18.1.1 Einfache Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
18.1.2 Erweiterte Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
18.1.3 Such-Chronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
18.1.4 Ergebnisanzeige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
18.2 Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
18.2.1 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
18.2.2 Dokumentenübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 269
18.2.3 Persönliche Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
18.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
18.3.1 Hauptnavigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
18.3.2 Navigation innerhalb der Seiten . . . . . . . . . . . . . . . . . . . . 271
19 Zusammenfassung und Bewertung 272
19.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
19.2 Erfahrungsberichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
19.2.1 Vorbereitungsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
19.2.2 Seminarphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
19.2.3 Erstellung des Kriterienkatalogs . . . . . . . . . . . . . . . . . . . . 274
19.2.4 Anforderungsdenition . . . . . . . . . . . . . . . . . . . . . . . . . 275
19.2.5 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
19.2.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
19.3 Bewertung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
19.4 Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
10

Inhaltsverzeichnis
III Anhang 281
A Inhalt der DVD 283
B Das Departmentfussballturnier 2005 285
C Glossar 287
D Verzeichnisse 295
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Listingverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
11

1. Einleitung
Bei diesem Dokument handelt es sich um den Endbericht der Projektgruppe PG.Portal.
Der Endbericht ist das Abschlussdokument des Projektes und gibt einen Überblick der
Arbeit und der Ergebnisse. In der Einleitung wird zunächst die Projektgruppe vorgestellt.
Danach wird die Motivation für die Arbeit erläutert und abschliessend die Struktur des
Endberichtes vorgestellt.
1.1. Die Projektgruppe PG.Portal
In der Studienordnung für den Studiengang Informatik der Carl von Ossietzky Universität
Oldenburg ist im vierten Studienjahr die Durchführung einer Projektgruppe vorgesehen.
Das Projekt hat eine Dauer von zwei Semestern und einen Umfang von 24 Kreditpunkten
(bzw. vier Modulen). Ziel der Projektgruppe ist es, eine Arbeit in einem Team zu entwickeln
und die damit verbundenen Wege und Mittel der Kommunikation und Organisation
in gröÿeren Arbeitsgruppen zu erlernen.
Die Projektgruppe PG.Portal besteht aus zwölf Studierenden und vier Betreuern. Zusätzlich
wurde die Projektgruppe noch von Mitarbeitern der Universitätsbibliothek beraten
und unterstützt. Ziel des Projektes war die Entwicklung von Bibliotheksdiensten für ein
Studierendenportal an der Universität Oldenburg. Der Bibliotheksdienst soll den Studierenden
als Teil eines Portals angeboten werden. Dabei sollten die Funktionen des schon
bestehenden Bibliotheksdienstes weitgehend übernommen und sinnvolle Erweiterungen
integriert werden.
Die Projektgruppe startete mit einer Seminarphase, in der jedes Mitglied der Projektgruppe
einen Vortrag und eine Ausarbeitung zu ausgewählten und projektrelevanten Themen
vorbereiten und präsentieren musste. Im Anschluss an die Seminarphase wurden anhand
eines Kriterienkataloges bestehende Bibliotheksdienste bewertet und die Ergebnisse analysiert.
Auf Grundlage dieser Ergebnisanalyse wurde die Anforderungsdenition erstellt
und ein entsprechendes Dokument angefertigt. Als nächstes wurden wichtige Entscheidungen
für die Systemarchitektur getroen und ein erster Prototyp entwickelt. Mit den
aus der Entwicklung des Prototyps gesammelten Erfahrungen wurde der Systementwurf
konkretisiert und das Entwurfsdokument angefertigt.
Bei der Implementierung wurde die Projektgruppe entsprechend der zu entwickelnden
Einzelkomponenten in vier Untergruppen aufgeteilt. Die einzelnen Gruppen waren für das
Benutzerkonto (Verwaltung der Benutzereinstellungen), Mediator/Wrapper (Kommunikation
mit verschiedenen Bibliothekssystemen), die Suchlogik (Suchfunktion und Ergebnisranking)
und die Benutzungsoberäche zuständig.
13

KAPITEL 1. EINLEITUNG
1.2. Motivation
Die Universität bietet den Studierenden verschiedene verwaltungstechnische Dienste (z.B.
Rückmeldung, Klausuranmeldung und Noteneinsicht) und Dienstleistungen (z.B. Internetzugang
und Bibliotheksfunktionen) über das Internet an. Damit der Student diese
Dienste in Anspruch nehmen kann, muss er sich in den verschiedenen Institutionen, die
den entsprechenden Dienst anbieten, anmelden und die zur Authentizierung nötigen
Benutzernamen und Passwörter zugeteilt bekommen. Die einzelnen Dienste haben unterschiedliche
Benutzungsoberächen und sind unter verschiedenen URLs erreichbar.
Da es für den Benutzer sehr umständlich ist, sich für jeden Dienst jeweils Internetadresse,
Benutzernamen und Passwort zu merken, wird in einem längerfristig angelegten, geförderten
Entwicklungsprojekt mit dem Namen i 3 sic! ein Studierendenportal entwickelt. In
diesem Portal werden die für das Studium wichtigen Prozesse zusammengefasst angeboten.
Somit wird es dem Studenten ermöglicht, auf alle wichtigen Informationen und
verwaltungstechnischen Dienste zuzugreifen. Das Studierendenportal ermöglicht es den
Benutzern auÿerdem, ihre Benutzungsoberäche an die eigenen Bedürfnisse anzupassen
und so schnell und problemlos alle Dienste zu nutzen, ohne sich bei jedem Subsystem
gesondert authentizieren zu müssen. Weitere Informationen zum i 3 sic!-Projekt können
in dem dazugehörigen Projektbericht nachgelesen werden.
Der von der Projektgruppe zu entwickelnde Bibliotheksdienst soll in dieses Studierendenportal
integriert werden. Der Hauptanteil liegt hierbei in der Ausarbeitung einer eektiven
Suchfunktion mit einer sinnvollen Präsentation der Suchergebnisse auf einem Bibliothekskatalog.
Dabei liegt der Schwerpunkt in der Integration des Oldenburger Regionales
Bibliotheks- und Informationssystem, kurz ORBIS. Es sollen aber auch externe Online-
Bibliotheken eingebunden werden. Im Vordergrund steht zudem noch die Entwicklung
einer benutzerfreundlichen und innovativen Arbeitsumgebung.
1.3. Überblick über den Endbericht
Dieser Endbericht ist in zwei Hauptteile aufgeteilt. Nach der Einleitung folgen im ersten
Teil die Seminarausarbeitungen. Jedes Projektgruppenmitglied musste sich in der Seminarphase
mit einem für das Projekt relevanten Thema auseinander setzen und dazu eine
Ausarbeitung anfertigen.
Der zweite Teil beinhaltet die Ergebnisdokumente der Softwareentwicklung. Dieser Teil
gliedert sich in die Abschnitte Bewertung von bestehenden Bibliotheksdiensten, Anforderungsdenition,
Entwurf, Implementierung und Zusammenfassung/Bewertung. Dabei
wurden zuerst anhand eines von der Projektgruppe entwickelten Kriterienkataloges bestehende
Bibliotheksdienste bewertet und die Ergebnisse analysiert. Die Anforderungsde-
nition besteht aus acht Kapiteln und beschreibt neben Ausgangssituation/Zielsetzung
und Systemeinsatz/Zielumgebung im Schwerpunkt die funktionalen und nichtfunktionalen
Anforderungen. Ausserdem werden die Anforderungen an die Benutzungsoberäche im
Fall von Fehlerverhalten und die Dokumentation beschrieben. Den Abschluss bilden die
Akzeptanzkriterien. Der nächste Abschnitt stellt den konzeptionellen Entwurf des Biblio-
14

1.3. ÜBERBLICK ÜBER DEN ENDBERICHT
theksdienstes dar und gliedert sich in die Teile Architektur, Suchlogik, Mediator/Wrapper,
Benutzerkonto, Benutzungsoberäche, Datenbankmodellierung und Testablauf. Als
nächstes folgt der Abschnitt Implementierung. Mit dem Kapitel Zusammenfassung und
Bewertung wird das Dokument abgeschlossen.
15

Teil I.
Seminarausarbeitungen
17

2. Was ist ein Web-Projekt
2.1. Was ist ein Webprojekt?
Woher soll man wissen, wann man angekommen ist, wenn man nicht weiÿ, wohin man
geht? Aus diesem Grund sollte zuerst allgemein ein Projekt, wenn es erfolgreich werden
soll, genauer deniert werden. Genauer gesagt, es werden ein Start- und ein Fertigstellungsdatum
benötigt. Zum Fertigstellungsdatum sollten das anfangs denierte Erfolgsziel
nebst einer zuvor erstellten Ergebnisliste erfüllt sein. Nicht zuletzt darf ein vereinbarter
monetärer Rahmen nicht überschritten werden. Im Vordergrund steht zudem der Kunde
als Auftraggeber, der zufriedenzustellen ist.
Nach einer allgemeinen Projektdenition kann jetzt der Begri Webprojekt im Speziellen
betrachtet werden. Hierbei handelt es sich um ein Projekt zur Erstellung oder Modizierung
einer Website, das in der Schnittmenge von IT- und Designprojekten anzusiedeln
ist. Schlieÿlich soll eine Website nicht nur gut funktionieren, sondern auch gut aussehen.
Webprojekte unterscheiden sich zum Teil grundlegend von anderen Projekten im Dienstleistungssektor.
So soll die Projektdauer bestenfalls ein halbes Jahr nicht überschreiten,
wobei aus Attraktivitätsgründen der Content (Inhalt) der Website nach Fertigstellung
ständig gepegt bzw. aktuell gehalten werden soll, was oft nicht weniger kostenintensiv
ist als das Projekt an sich. Da mit einer Website zumeist Menschen unterschiedlichster
Eigenschaften angesprochen werden, sollte sie für alle nutzbar sein und ansprechend
wirken.
2.2. Wie unterscheiden sich Webprojekte
voneinander?
In der Geschäftspraxis werden Webprojekte nach bestimmten Kriterien eingeordnet. Zum
einen wird unterschieden, ob es im eigenen Haus benötigt (Internes Projekt) oder an
einen externen Auftraggeber abgegeben wird. Bei einem groÿen Projekt werden zum anderen
mehrere Teilprojektleiter beschäftigt, die sich meistens einem Vollzeit-Projektleiter
unterordnen, während bei einem kleinen Projekt ein einzelner Leiter voll ausreicht. Desweiteren
kann der Leistungsumfang unterschiedlich ausgeprägt sein und sich irgendwo
zwischen einer Wartung und einer groÿ angelegten Neugestaltung benden.
Auch die Art der Website trägt zur Klassizierung eines Webprojektes bei, vom Inhalt
über (interner oder externer) Erreichbarkeit, Anzahl der verwendeten Sprachen und Techniken
bis zu ihren Sicherheitsanforderungen.
19

KAPITEL 2. WAS IST EIN WEB-PROJEKT
2.3. Wer bestimmt in einem Webprojekt?
Hier gibt es zwei Parteien: den Auftraggeber bzw. den Kunden, und den Auftragnehmer als
Dienstleister, der das Webprojekt erstellt. Beide Parteien sind unterteilt in Projektleiter
und Team, wobei die Kundenpartei nicht zwingend ein Team besitzen muss und zusätzlich
einem Entscheider untergeordnet ist, der u.a. über das Budget verfügt und beispielsweise
den Job des Abteilungsleiters ausübt. Handelt es sich um ein internes Webprojekt, können
verschiedene gleichrangige Rollen zusammenfallen.
jedoch ist die Realisierung eines Webprojekts auÿer von diesen beiden Parteien noch von
anderen abhängig, wie z.B. der Einkaufsabteilung, die das Projekt einer Prüfung unterzieht,
und den Stakeholdern, die vom Projekt irgendwie berührt werden, auf der Kundenseite,
sowie auf Dienstleisterseite einem Accountmanager, an den sich der Kunde wendet,
falls ein Problem nicht über den Projektleiter beseitigt werden kann, in Zusammenwirkung
mit einem weiteren Entscheider.
Abbildung 2.1.: Projektorganisation und Umfeld
Wenn das Projekt eine bestimmte Gröÿe überschreitet, werden zentrale, das Projekt betreende
Entscheidungen von einem Steuerungsausschuss getroen, der aus dem Entscheider
der Kundenpartei, dem Accountmanager der Dienstleisterpartei, den Projektleitern
und den Vertretern einiger Stakeholder besteht. Eine groÿe Kundenrma kann aus ähnlichen
Interessen einen Lenkungsausschuss erstellen. Ob diese beiden Gremien leichter fähig
sind Entscheidungen zu treen, wird in diesem Rahmen jedoch nicht weiter behandelt.
2.4. Was ist zu tun?
Genauso wie Projekte im Allgemeinen lassen sich auch Webprojekte in drei Phasen einteilen:
In der Vorbereitungsphase wird eine Idee zu einem Projekt konkretisiert, in der
Durchführungsphase wird das Projekt durchgeführt und schlieÿlich in der Nutzungsphase
angewendet.
Die Phase der Durchführung kann im Fall eines Webprojekts wiederum unterteilt werden
in eine Vorbereitungszeit der Zusammenarbeit (Kick-O), die Ist-Beschreibung, das
Gesamtgrobkonzept, die Design- und die IT-Phase.
20

2.4. WAS IST ZU TUN?
Abbildung 2.2.: Phase der Durchführung
Im Folgenden werden die wichtigsten Projektschritte eines Webprojekts ausführlich dargestellt.
1. Vorbereitung
a) Projektidee
• Hauptrollen: Entscheider und Antragsteller
• Aufgaben: Erstmaliger Entwurf einer Idee; Ziele, Nutzen, Notwendigkeit
• Ergebnis: Skizze der Idee, Notwendigkeit der Weiterverfolgung der Idee
b) Beauftragung des Kundenprojektleiters
• Hauptrollen: Projektleiter und Entscheider der Kundenpartei
• Aufgaben: Ernennung des Projektleiters
• Ergebnis: Projektleiter wurde auserwählt, ist willig und sich seiner Aufgabe
bewusst
c) Interne Projektdenition
• Hauptrollen: Projektleiter und Entscheider
• Aufgaben: Festlegung des zu erreichenden Zieles: grobe Projektdenition
seitens der Kunden und häuge Präsenz des Entscheiders, dann Entscheidung
über Weiterverfolgung des Projekts
• Ergebnis: Priorisierte Liste von Anforderungen, Ziel, Zeitrahmen, Kooperation
der Stakeholder, grobe Kosten-Nutzen-Analyse
d) Beauftragung des Dienstleisters
• Hauptrollen: Entscheider und Projektleiter auf Kundenseite, Akquiseteam
auf Dienstleisterseite
• Aufgaben: Prüfung der und Entscheidung über die Ressourcen, Präsentation
der Dienstleister und ihrer Angebote sowie Vertragsunterzeichnung
bei externer Projektvergabe
• Ergebnis: Ausschreibung, kundenseitige Entscheidung über Weiterverfolgung
des Projekts, Vertrag oder Vorvertrag, Geheimhaltungsvereinbarung
e) Beauftragung des Projektleiters auf Dienstleisterseite (parallel zu Schritt 1. d))
21

KAPITEL 2. WAS IST EIN WEB-PROJEKT
2. Durchführung
• Hauptrollen: Projektleiter der Dienstleisterpartei, sein Vorgesetzter, Accountmanager
• Aufgaben: Beauftragung des Projektleiters
• Ergebnis: Projektleiter wurde auserwählt, ist willig und sich seiner Aufgabe
bewusst
a) Kick-O: Vorbereitung der Zusammenarbeit, erstes Treen beider Parteien
• Hauptrollen: Projektleiter beider Parteien, Entscheider und weitere
• Aufgaben: Gegenseitige Vorstellung, Formalitäten vor der eigentlichen Arbeit
• Ergebnis: Übergabe vorhandener Dokumente, Kontakt zu relevanten Personen,
Organisatorisches (Adresslisten, Urlaubsplanung, Termine für Meetings,
gemeinsame Dokumentenhaltung)
b) Ist-Beschreibung und Pichtenheft: Was ist da und was wird benötigt?
• Hauptrollen: Projektleiter und erfahrene Mitarbeiter beider Parteien
• Aufgaben: Sammlung von Informationen über gegenwärtigen Zustand und
Anforderungen des Kunden an den Dienstleister
• Ergebnis: Ist-Beschreibung (Design-Ist, IT-Ist,...), Pichtenheft (Beschreibung
der Zielgruppe und ihre Bedürfnisse, Priorisierte Anforderungen:
Kundenvorgaben/- wünsche, Domainkonzept/-sicherung, Liste der im Grobkonzept
zu treenden Entscheidungen), geschäftlicher Sinn des Projekts
(Ziel, Geschäftsmodell)
c) Gesamtgrobkonzept: Treen der grundlegenden Entscheidungen
• Hauptrollen: Projektleiter und erfahrene Mitarbeiter beider Parteien
• Aufgaben:
Positionierung für die Zielgruppe (Nutzen, Markenwerte)
Grobe Use Cases (Was können User in dieser Site tun? Welche Aktionen
sind in der Contentpege möglich?)
Grobe Übersicht des Content
Gegebenenfalls Personalisierungskonzept
Gegebenenfalls grobes Internationalisierungskonzept
Grobes Marketingkonzept (Wie werden Nutzer gewonnen?)
IT-Ziele (Performance, Sicherheit)
IT-Lösungsidee und Machbarkeit (Daten, Technologie, Organisatorisches,
Integration)
Grobe IT-Architektur (Softwareprodukte, Hardware, Standort)
Prototypen
d) Design
22

2.4. WAS IST ZU TUN?
e) IT
• Hauptrollen: Mitarbeiter
• Aufgaben:
Informationsarchitektur
∗ Use Cases (detaillierte Handlungsabläufe des Nutzers)
∗ Beschreibung des Content (Inhalte und Funktionalitäten)
∗ Contentogramme (Inhaltmodule und ihre gegenseitige Vernetzung)
∗ Navigationskonzept
Audio-visuelles Konzept (Detailkonzeption der gestalterischen Maÿnahmen,
die unmittelbar zur Implementierung des Designs führen)
Styleguide
Medienproduktion
Usability-Tests (während des gesamten Designprozesses)
• Hauptrollen: Mitarbeiter
• Aufgaben:
Etablierung der IT-Struktur für Softwareentwicklung, Integration, Roll-
Out und Betrieb (Softwareprodukte, Hardware, Netzwerke, Kongurationsmanagement,
Provider)
IT-Feinkonzept (detailliertes Konzept für die Umsetzung des Grobkonzepts
und des Designs, führt unmittelbar zur Implementierung)
Softwareentwicklung
IT-Tests
Usability-Tests (Fortführung der Tests aus Punkt 2.d) Design)
Dokumentation (für Wartung und spätere Änderungen)
f) Launch und verschiedene Vorbereitungsschritte
• Hauptrollen: Mitarbeiter
• Aufgaben:
Schulung des Personals für den Betrieb
Abnahmetest
Eventuell Betrieb im eingeschränkten Rahmen (mit Feedback)
Launch (Website online schalten, d.h. Start der Nutzung)
g) Marketing: für die entstehende Seite werben
3. Nutzung
• Hauptrollen: Mitarbeiter
• Aufgaben: Marketingkonzept (online und oine), Marketing-Roll-Out (Werbung)
a) Betrieb und Pege
23

KAPITEL 2. WAS IST EIN WEB-PROJEKT
• Hauptrollen: Nutzer
• Aufgaben: Pege des Content, Wartung, technische Administration
[Sto04]
Dieses Beispiel eines Projektablaufs geht von einem gröÿeren Webprojekt aus. In der
Realität sind diese Projekte selten so umfangreich, dass alle oben genannten Punkte ausführlich
behandelt werden müssen. Trotzdem ist es sinnvoller eine derartige komplette
Übersicht zu haben, damit die zuständigen Führungskräfte die einzelnen Punkte abwägen
können. Wie bereits erwähnt, handelt es sich hier lediglich um ein Beispiel, welches
als erste Orientierung angesehen und durchaus noch individuell modiziert werden kann.
Auÿerdem lässt es sich sowohl bei wiederholender (iterativer), als auch bei Wasserfall-
(sequeltieller) Vorgehensweise anwenden. Da in der Ausarbeitung Planung von Webprojekten
näher auf die Projektplanung eingegangen wird, werde ich diesen Aspekt an
dieser Stelle vernachlässigen.
2.5. Wer ist an einem Webprojekt beteiligt?
Abbildung 2.3.: Beispiel für Mitarbeitereinsatz im Projektverlauf
Dieses Diagramm zeigt, wie verschiedene Mitarbeiter im Verlauf des Projekts eingesetzt
werden können. In der Realität können die Abweichungen von diesem Beispiel projektabhängig
unterschiedlich stark ausgeprägt sein. Auÿerdem ist der Einsatz von Beratern
in vielen Bereichen oft sinnvoll. Neben Prozess- und Strategieberatern, die auch Managementberater
genannt werden, kommen gegebenenfalls auch Senior-Mitarbeiter mit gröÿerer
Erfahrung zum Einsatz. Für branchenspezisches fachliches Wissen sorgen sogenannte
fachliche Mitarbeiter auf Kundenseite, die nicht nur während der Planungsphase, sondern
auch später zur Kontrolle und Prüfung benötigt werden. Um sicherzustellen, dass die erstellte
Website zur Marke passt, bekannt wird und vielleicht auch selbst Werbung trägt,
24

2.6. WAS MACHT DEN ERFOLG AUS?
werden Marketing- und Branding-Experten eingesetzt. Das Projektteam selbst, welches
den Groÿteil der Projektarbeit leistet, besteht aus IT-Experten und Designern. Für die
Contentpege nach Fertigstellung des Projekts sorgen Redakteure. Auch Juristen kommen
zum Einsatz, wenn die Zusammenarbeitsverträge zwischen den zwei Parteien erstellt
werden oder Streitigkeiten beseitigt werden sollen.
2.6. Was macht den Erfolg aus?
Nach einer Untersuchung der Timekontor AG im Berliner und Brandenburger Raum wird
von drei Internetprojekten im Durchschnitt eins abgebrochen, wobei 75% der abgebrochenen
Projekte nicht einmal ansatzweise die gesetzten Ziele erreicht. Von jeweils 12
Intranetprojekten scheitert eins. Im Jahr 2002 [2000] wurden 15% [23%] aller IT-Projekte
mit zu implementierender Anwendung abgebrochen, während 51% [49%] nanzielle oder
zeitliche Rahmen verfehlten, oder die gestellte Anforderungsdenition nicht komplett erfüllten.
Die Bedingungen für den Abbruch eines Projekts sind nicht fest deniert, so dass
Projekte auch erfolgreich sein können, wenn sie ein Vielfaches an Kosten verschlingen,
was am Beispiel der Entwicklung der deutschen LKW-Maut zu erkennen war.
Wenn man sich wagt ein normales Webprojekt zu implementieren, muss man sich bewusst
sein, dass die Wahrscheinlichkeit des totalen Versagens nicht gerade klein ist. Eine
Verkleinerung der IT-Projekte, reifere Technologien und Methoden, sowie ein gestiegenes
Risikobewusstsein bewirkten, dass sich im Jahr 2000 etwa 28% von ihnen im zeitlichen,
nanziellen und funktionellen Rahmen befanden, während es 1993 noch lediglich halb so
viele waren.
Eine weitere Grak illustriert die wichtigsten Probleme während der Entwicklung eines
Webprojekts, wobei berücksichtigt werden muss, dass die meisten Probleme in der Anfangsphase
verursacht werden und erst später sichtbar werden.
25

KAPITEL 2. WAS IST EIN WEB-PROJEKT
Abbildung 2.4.: Projektprobleme
Die Tatsache, dass ein Projekt erfolgreich wird, hängt von vielen Faktoren ab, nicht zuletzt
vom Entscheider der Kundenpartei und den Projektleitern beider Parteien. je mehr
Abteilungen über das Projekt bestimmen dürfen und je stärker sich daher die Anforderung
und die Umwelt ändern, desto wahrscheinlicher ist es, dass das Projekt scheitert.
Zur Steigerung der Erfolgswahrscheinlichkeit sollte unter anderen besonders der Entscheider
das Projekt voll unterstützen. Ein Webprojekt muss auÿerdem eine inhaltliche Basis
enthalten und bezüglich seiner Kosten und Nutzen bewerten worden sein. Im Team sollten
kommunikative Barrieren vermieden werden. Und die zuständigen Projektleiter und
Entscheider sollten sich in ihren Parteien gut auskennen und ihre Aufgaben erfüllen. Ein
Fehlen eines oder mehrerer dieser ausgewählten Aspekte kann sich ebenfalls negativ auf
das Projekt auswirken.
26

2.7. Was macht die Kosten aus?
2.7. WAS MACHT DIE KOSTEN AUS?
Abbildung 2.5.: Kosten im Zusammenhang mit einem Webprojekt
Da eine fertiggestellte Webseite natürlich inhaltlich und technisch gepegt werden muss,
kann, abhängig von der Ausprägung der Pege, ein Groÿteil der Kosten auf die laufenden
Kosten entfallen. Die einmaligen Kosten lassen sich in fünf Bereiche unterteilen, die
überwiegend gleichbedeutend sind (Tabelle).
Bisher haben wir gelernt, dass Webprojekte häug scheitern und aus diesem Grund von
vornherein ein Risiko sind. Daher ieÿen nicht nur die Aufgaben der Kundenpartei in die
Kosten eines Webprojekts ein, sondern auch das Risiko, welches auch von den beteiligten
Personen, Firmen und dem ganzen Umfeld beeinusst wird. Zuletzt genannte Faktoren
können bei derselben Aufgabenstellung jeder Kundenrma einen anderen Preis bescheren.
Für die Dienstleistungspartei zahlen sich Erfolge dafür umso mehr aus.
Zuletzt noch eine Übersicht der nanziell besonders schwerwiegenden Aspekte in Webprojekten:
• Internationalisierung
• Sehr neuartige Vorhaben, es gibt bisher nichts Ähnliches im Internet
• Besondere Anforderungen an die Inszenierung von Marken (Top-Markenunternehmen)
• Personalisierung
• Community-Features
• Spiele
• Shop
• CMS
• Komplexer Workow für die Contentverwaltung
• Funktionen, insbesondere solche, die technisch nicht allein innerhalb der Website
operieren; Transaktionen mit Waren oder Geld
27

KAPITEL 2. WAS IST EIN WEB-PROJEKT
• Hochleistung
• Hohe Sicherheitsanforderungen
• Anzahl der Seiten der Website
• Unerprobte Technologie
• Organisatorischer Faktor (viele Stakeholder, Groÿunternehmen, viele Vorschriften,
langsame Entscheidungsprozesse)
• Persönlicher Faktor (schwierige Beziehungen, unerfahrene Führungskräfte)
• Mangelnde Erfahrung mit ähnlichen Projekten in der Organisation, fehlende Ressourcen
mit Erfahrung
• Änderungsfreudiges Projektumfeld (Geschäftslage, Marktlage, Kundenbedürfnisse,
Umstrukturierungen etc.)
• Unklare Ziele und Änderungen der Ziele
2.8. Fazit
Die auf den in der Projektgruppe gehaltenen Vortrag zu dieser Ausarbeitung folgende
Diskussion stärkte die Klarheit, dass sich ein Webprojekt nicht allzu stark von einem
normalen Projekt unterscheidet.
Unserer Gruppe wurde auÿerdem am eigenen Beispiel klar, dass die in dieser Ausarbeitung
als vorbildlich gesammelten Regelungen nicht uneingeschränkt gültig sind. Obwohl ein
Webprojekt möglichst nicht länger als ein halbes Jahr dauern sollte, wird unseres ein
ganzes Jahr dauern. Unser Webprojekt ist jedoch Teil der Ausbildung von Studenten, so
dass unter anderem die Erlernung und Vertiefung angewendeter Verfahren ein weiterer
Aspekt der Veranstaltung ist, welcher das Projekt in die Länge zieht.
28

3. Planung von Web-Projekten
3.1. Einleitung
3.1.1. Allgemeine Einleitung
In immer mehr Bereichen wird die Massenproduktion von Waren durch Herstellung von
kundenspezischen innovativen Produkten ersetzt. Möglichst schnell, jedoch doch individuell.
Forschung und Entwicklung wird dabei immer wichtiger. Es entstehen viele Einzelvorhaben,
die ein vernünftiges Projektmanagement Notwendig machen. Die Anfänge des
Projektmanagements werden auf das Apollo Projekt der NASA zu Beginn der 60er Jahre
zurück. Man musste eine enge Verechtung von Forschern, Ingenieuren und Institutionen
unter hohem Zeitdruck (der Wettlauf mit den Sowjets) koordinieren. Dieses Dokument
befasst sich aber nicht mit der Historie der Projektplanung oder die Gestaltung solcher
Groÿprojekte. Sondern mit der Planung von Webprojekten. Webprojekte sind in sich geschlossen
und nutzen die weltweite Plattform Internet als Verbreitungsmöglichkeit. Für
ein Webprojekt ist ein klares Konzept neben den technischen Voraussetzungen für einen
guten Web Auftritt maÿgeblich.
3.1.2. Strukturelle Einleitung
Dieses Dokument benutzt hauptsichtlich als Informationsquelle den 3 Kapitel des Buchs
Management von Webprojekten - Führung, Projektplan, Vertrag [Sto04] . Daher ist
die Struktur des Dokuments diesem Kapitel sehr ähnlich. Jedoch wurde zur Ergänzung
dieser Quelle weitere Quellen aus dem Internet hinzugenommen [BO] [vir] [Sel] [TO].
Daher stehen hier auch ein paar Informationen, die im erwähnten Buch nicht stehen.
Gröÿtenteils werden die Informationen in diesem Dokument stichwortartig aufgezählt.
Das hat den Sinn, viel Wissen auf wenige Seiten zu bündeln ohne dabei die Übersicht zu
verlieren.
3.2. Wie genau sind die Kosten planbar
Kostenschätzung und Terminplanung sind erst auf Grund erarbeiteter Informationen möglich.
Daher, um Kosten vernünftig zu planen, braucht man zunächst die dazu benötigten
Informationen. Diese Informationen ergeben sich hauptsichtlich aus der Ist-Situation (Ist-
Beschreibung), die Anforderungen (Pichtenheft) und dessen Umsetzung (Grobkonzept).
Weiter kann man das Grobkonzept in einen Feinkonzept führen.
29

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
Durch das Pichtenheft und der Ist-Beschreibung kann man ungefähr die Gröÿenordnung
der Projektkosten ermitteln, d.h. wie viele Stellen der Betrag hat. In dem Pichtenheft ist
eine detaillierte Liste der Anforderungen ans Projekt angegeben. Daran erkennt man die
Hauptkostenfaktoren. Das Grobkonzept ermöglicht die Ermittlung der Kosten um eine
30 Prozent Genauigkeit. Beim Grobkonzept müssen die wichtigsten Entscheidungen zur
Umsetzung des Projekts bereits gefallen sein. Das Feinkonzept wird in der Regel nach dem
Design erzeugt, daher ist an dieser Stelle eine sehr genaue Kostenabschätzung möglich.
Im Allgemeinen gilt für die einzelnen Projektschritte, dass dessen Aufwand am Ende des
vorherigen Schritts sehr genau einschätzbar ist. Das gilt aber nicht für die Kosten, sondern
auch für den Projektplan und Fertigstellungstermin.
3.3. Schätzen
Das Schätzen ist sehr elementar um frühzeitig die Kosten oder den Zeitaufwand einzusehen.
Nur so erkennt man, ob ein Projekt überhaupt Sinn macht. Gute Schätzungen hängen
von mehreren Personen und dessen Zusammenarbeit in einer Gruppe ab. Die Qualität dieser
Schätzungen ist ein Produktivfaktor mit dem Geld gespart oder verdient wird. Der
Auftraggeber des Projekts benötigt diese Schätzungen um das Kosten-Nutzen-Verhältnis
einer Investition zu bestimmen. Der Auftragnehmer kann erst durch die Schätzungen ein
wettbewerbsfähiges Angebot erstellen, bei dem man vernünftig auf die Anforderungen
und dessen Machbarkeit geachtet hat und bei dem der eigene Gewinn natürlich nicht zu
kurz kommt.
3.3.1. Das Ergebnis einer Schätzung
Das Ergebnis einer Schätzung hängt natürlich von den Fragen ab, die man beantwortet
haben will. Die Fragen beim Schätzen lauten im Allgemeinen bei der Projektplanung,
• mit welchen eigenen Aufwand,
• welchem Beitrag eines Dritten
• und bis wann ist das Ziel erreicht?
Diese Punkte sind nicht nur zu benennen, sondern müssen auch aufeinander abgestimmt
werden.
Das Ergebnis der Schätzung ist ebenfalls eine Untergliederung der Leistungen. Dabei ist
es auch gut Ausschlüsse zu benennen. Das sind Punkte die fälschlicherweise als Anforderungen
deniert werden könnten, jedoch schon erfüllt sind oder durch einen Dritten bearbeitet
werden. Weiterhin sollten oene Fragen oder mögliche Risiken bestimmt werden.
Diese sind noch nicht mit einer verantwortungsvollen Abschätzung klärbar. Zunächst wird
nur ein vernünftiger Aufwandsaufschlag bestimmt. Sie werden später im Risikomanagement
weiter behandelt. Am Ende werden noch die Erforderlichen Sachkosten ermittelt.
Diese Sachkosten entstehen durch Schulungen für Mitarbeiter, besondere Entwicklung-
30

3.3. SCHÄTZEN
oder Testsoftware oder -hardware und eventuell auch durch Reisekosten. Jedoch werden
die Sachkosten nur erwähnt, wenn sie nur für dieses Projekt gelten. Auÿerdem werden
im Allgemeinen die Schulungen und das Arbeitsmaterial aus dem eigenen Firmenbudget
bezahlt.
Die Hauptaufgabe ist die Schätzung der Kosten (Bsp. die Löhne) der teilnehmenden Personen.
Diese Abschätzung ist abhängig von den Tagessätzen, die einer Mitarbeitergruppe
erhält und die Dauer in der man diese Gruppe beansprucht. Nach der Multiplikation der
Tagessätze mit der Dauer und die Addition des Ganzen erfolgt der Gesamtpreis.
Risikomanagement
Als Risiko gilt beim Projektmanagement grundsätzlich alle Unwägbarkeiten, die den Projekterfolg
hinauszögern oder gefährden können. Ein Risiko kann unerwartet eintreten.
Doch oft ist er schon am Projektanfang vorhersehbar. Um solche Probleme zu umgehen
wird am Start eines Projektes eine Risikoanalyse vollzogen. Nach dem Erkennen eines
Risikos erfolgt die Gestaltung von Vorkehrungen zum lösen oder Vermeiden des Problems.
Alles wird dann in einer Tabelle eingetragen, um immer wieder darauf zugreifen
zu können. Während des Projektverlaufs sollte man die Risiko-Tabellen immer wieder
überprüfen. Manchmal lösen sich Risiken durch neue Informationen oder Entwicklungen
in Luft auf; oder es entstehen neue Risiken.
3.3.2. Erstellen einer Schätzung
Der Erste Schritt ist die naive Schätzung. In ihr wird stichpunktartig jede Anforderung des
Projektes erklärt, welche Punkte man dafür im Einzelnen schon erzielt haben muss oder
durch sie erzielt werden. Anschlieÿend werden noch diese Punkte mit einem möglichen
Aufwand beschrieben, der auf die eigenen Erfahrungen basiert. Dadurch entsteht eine
Aufwandsuntergliederung.
Diese Untergliederung wird im nächsten Schritt überprüft und verfeinert. Dabei soll ein
qualitatives Niveau erreicht werden, das den folgenden Verwendungszwecken genügt.
• Aufwandskalkulation
• Projektplanung
• Projektcontrolling
Um die gewünschte Qualtität zu erreichen sollte man bei der Überprüfung und Verfeinerung
bestimmte Punkte beachten.
• Es sollten konkrete Teilergebnisse benannt werden (Bsp. Kunden-Newsletter alle 2
Wochen)
• Die Aufwandspunkte sollten ungefähr eine Gröÿe haben. Sonst sollten sie weiter
untergliedert werden.
31

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
• Riskante Aufwandspunkte sollten markiert werden und genauer untersucht werden.
• Weiterhin sollte man nie das Vergessen vergessen. Daher sollte man bei den Schätzungen
immer einen kleinen Puer berücksichtigen.
• Projektleitungs- und Kommunikationsaufwände sind auch Aufwände.
• Es zählen auch menschliche Schwierigkeitsfaktoren, wie Krankheit oder ähnliches
• Immer die übergeordneten Ziele und die kritischen Erfolgsfaktoren im Auge behalten.
• Man muss auch beachten, dass man bei einigen Punkten zu wenig Erfahrung hat
um sie genau zu bewerten. Dann sollte man es entweder den anderen die Bewertung
überlassen oder wenigstens 10-20 Prozent auf der gefühlten Wertung dazu rechnen.
• Dinge, die man nicht einschätzen kann, sollten markiert und später weiter besprochen
werden.
• Die Dauer der Schätzung sollte in einem vernünftigen Rahmen bleiben. Aber auch
nicht zu schnell abgeschlossen werden.
Aufgliederung bestimmter Aufwandspunkte
Wie schon mal erwähnt, muss man zu groÿ geratene Aufwandspunkte (Dauer oder Aufwand)
weiter untergliedern. Dabei richtet man sich nach folgenden Punkten: Aufgliederung
...
• nach inhaltliche, strukturelle Teile
• gemäÿ Arbeitsablauf
• nach Use Cases des Nutzers
Anforderungen
Da immer wieder über Anforderungen gesprochen wird. Hier noch ein paar Hinweise, die
man dazu beachten sollte. Es ist hilfreich den Anforderungen Prioritäten zu zu ordnen. So
kann man erkennen, welche unbedingt notwendig sind oder welche man notfalls weglassen
kann. Dafür gibt es mehrere mögliche Methoden.
Eine Möglichkeit ist es, die Anforderungen in MUSS, SOLL oder KANN aufzuteilen.
• MUSS: Ohne diese Anforderungen ist das Vorhaben nicht sinnvoll
• SOLL: Diese Anforderungen sollte man wenn möglich umsetzen
• KANN: Anforderungen, die eine Art Bonus darstellen (nice to have)
32

3.3. SCHÄTZEN
Eine andere Methode ist das Paretoprinzip, wonach in vielen Zusammenhängen ein kleiner
Teil der Dinge den überragenden Anteil des Eektes ausmacht. Oft gibt es ein kleiner
Kern der Anforderungen, die den eigentlichen Gesamt-Eekt ausmachen. Diese Anforderungen
werden bestimmt und zum Gesamtinhalt des Projektes benannt. Um weiter
Ergänzungen vorzunehmen wird dann ein neues Projekt gestartet.
3.3.3. Erfahrungswerte zum Vergleichen
Die fertige Schätzung kann man durch allgemeine Erfahrungswerte vergleichen. Aus der
Sicht des Zeitbedarfs sind die groÿen Blöcke:
• Konzeption
• Implementierung
• Test und Verbesserung
• Projektleitung
• Gewährleistungspichten gegenüber dem Kunden
Für kleine oder mittlere Projekte gilt bei der Zeitverteilung; 1/3 Konzeption, 1/3 Implementierung,
1/3 Test und Verbesserung. Bei groÿen Projekten verbraucht die Konzeption
mehr Zeit als die restlichen Punkte zusammen.
Proportional zum Gesamtaufwand der Projektdurchführung gelten folgende Punkte:
• Übersehene Aufwände (10-20 Prozent)
• Projektleitung (20-25 Prozent)
• Gewährleistung des Dienstleisters an den Kunden (15 Prozent für 12 Monate)
3.3.4. Typische Schätzfehler
Es gibt immer wieder Bedingungen die Schätzfehler provozieren.
• Bevor die Schätzung durchgeführt wurde, bestehen schon Erwartungen an ihr.
• Druck zur Kürzung der Schätzung durch Chef oder Kunden.
• Bedingungen für eine Zeitverkürzung werden nachträglich unterschlagen.
• Aufwände werden vergessen.
• Nicht genügend oder die falschen Schätzer werden gefragt.
• Generell persönlich Tendenzen zu Fehleinschätzungen.
• Überschätzung durch zu detaillierte Aufgliederung der Schätzung.
33

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
3.4. Allgemeine Einführung zu Schätzmethoden
3.4.1. Methoden
Die Analogieschätzung beruht darauf eine oder mehrere ähnliche vergangene Projekte
als Vergleichsbasis heranzuziehen um das aktuelle Projekt einzuschätzen. Am Besten
bezieht man sich auf Projekte zum Vergleich an dem man selbst beteiligt war; oder die
ausführlich Dokumentiert wurden.
Die Expertenschätzung entsteht, indem Experten den Schätzgegenstand in einzelne
Punkte untergliedern. Darauf wird dann der Aufwand der einzelnen Punkte eingeschätzt.
Dabei verlässt man sich auf die Erfahrung der Experten. Es gibt unterschiedliche Arten
des Ablaufs von Expertenschätzungen:
• Die Einzelschätzung, wobei nur eine Person die Schätzung vollzieht.
• Das Zusammenrechnen mehrerer Einzelschätzungen (z.B. Durchschnitt).
• Die Delphi-Methode (entwickelt von RAND-Corporation und O. Helmer). Hier werden
auch Einzelschätzungen zusammengerechnet, jedoch wird auf Anonymität geachtet,
um Beeinussungen zu vermeiden.
• Der genaue gegen Schritt zur Delphi-Methode ist die Schätzklausur. Hier wird oen
in der Gruppe geschätzt. Hier ist der Vorteil gleich auch der Nachteil. Es wird
nämlich der freie Informationsaustausch gefördert.
Bei der Kennzahlmethode wir eine Formel zur Einschätzung des Aufwands zu Rate
gezogen.
Es gibt einige solche Schätzverfahren, wie CoCoMo, Function Point oder Object Point.
• Das CoCoMo Verfahren basiert auf die Betrachtung der Lines of Code und dessen
prozentuale Aufwandverteilung auf den verschiedenen Projektphasen.
• Bei der Function-Point Methode werden zunächst Komponenten wie Input-, Outputwerte,
Relationen usw. bestimmt. Darauf werden diesen Komponenten Funktionspunkte
je Komplexität zugeordnet. Anschlieÿend werden noch die Einussfaktoren
bewertet und dann gerechnet.
• Die Object-Point Methode ist die Anpassung der Function-Point Methode auf eine
objektorientierte Entwicklung. Dafür wird die Anzahl der Klassen, Botschaften und
Geschäftsprozesse betrachtet.
Jedoch sind die Kennzahlmethoden für ein Web-Projekt nicht wirklich relevant, da sie
nur den IT-Aspekt berücksichtigen. Sie sind auf Design, Branding oder Consulting nicht
anwendbar.
34

3.5. SCHÄTZUNG IM TEAM
3.4.2. Strategien
Es gibt unterschiedliche Formen, bei denen man entweder aus dem Preis die Leistung
oder aus der Leistung der Preis abgeleitet wird.
Beim Bottom-up werden aus den Teilen des Projekts die Kosten hergeleitet. Ein Beispiel
ist Expertenschätzung.
Der Top-down Ansatz geht vom umgekehrten aus. Der Gesamtaufwand wird zunächst
eingeschätzt und dann auf die Teile des Projektes verteilt.
Beim Target Costing ist der Preis schon fest und danach muss sich dann das Projekt
richten.
3.4.3. Wahl der Schätzmethoden
Vor der Projektdenition dient das Pichtenheft zur Vorbereitung des Projektes. Dieses
wird am besten durch die Analogiemethode erzeugt. Nach der Projektdenition (Pichtenheft
ist erstellt) werden die Experten zu Rate gezogen. Es folgt die Expertenschätzung,
die man wiederum durch die Analogiemethode absichern kann.
Bei kleinen Projekten wird tendenziell schon früher die Expertenschätzung durchgeführt.
Da hier schon oft durch eine konkrete Projektzieldenition die Grundlage für die Experten
vorhanden ist.
3.5. Schätzung im Team
3.5.1. Leitung der Schätzung im Team
Es wird gerne im Team geschätzt. Durch ein ausgewogenes Team sind gleich mehrere
Blickwinkel auf das Thema möglich. Es ist aber auch die einzige Methode relativ schnell
eine Schätzung vorzunehmen. Innerhalb einer Gruppe muss man aber unbedingt drauf
achten, dass alles im richtigen Rahmen verläuft. Sonst erlangt man nicht die gewünschte
Eektivität. Daher wird immer ein Moderator der Gruppe bei Seite stehen müssen, der
die Gruppe fördert und vorbereitet.
Hier sind einige Ablaufschritte aufgezählt, die man befolgen sollte (dafür ist hauptsichtlich
der Projektleiter zuständig):
• Der Projektleiter bestimmt die Schätzmethoden und dessen Arbeitsprozess. Er sollte
selbst schon vorher eine leichte Abschätzung im Hinterkopf haben.
• Es sollte ein vernünftiger Zeitrahmen vorhanden sein. Man sollte immer dabei die
Projektgröÿe, den Projekttyp und Konsequenzen einer Fehleinschätzung in Betracht
ziehen. Bei einem Projekt von 100 Personentagen (PT) sollte man schon 3PT für
die Schätzung opfern.
• Alle grundlegende Fragen sollten geklärt und das benötigte Informationsmaterial
für alle gribereit vorhanden sein.
35

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
• Das Team sollte aus wenige sehr erfahrene Leute bestehen. Es müssen jedoch mindestens
alle benötigten Disziplinen vertreten sein. Anfänger müssen beteiligt werden,
wenn sie dadurch geschult werden sollen oder sie bei der Ausführung einen wichtigen
Teil mit übernehmen.
• Wenn die Projektaufgabe deutlich nach Disziplinen aufteilbar ist, sollten passend je
Disziplin Schätzteams von mindestens 2 Personen gebildet werden.
• Nachdem eine Liste der aufwandsrelevanten Punkte erstellt wurde, wird nun dessen
Aufwand bestimmt. Das Folgt durch eine Einzelabschätzung mit anschlieÿender
Gruppendiskussion. Es sollte ersichtlich werden, warum die Personen ihre Entscheidungen
gefallen haben. So werden alle möglichen Mehraufwände oder Erleichterungen
ersichtlich.
• Am Ende muss das Ergebnis für einen möglichen Dritten noch verständlich aufbereitet
werden.
Einzelne Beispiele für Arbeitsprozesse (bei allen wird ein Zeitrahmen vorgegeben):
• Brainstorming ist bei gutem Informationsstand der Beteiligten empfehlenswert.
• Einzelarbeit mit anschlieÿender Diskussion.
• Wenn viele Dokumente als Informationquelle zum Ganzen durch genommen werden
müssen, kann man die Schätzung auch als Hausaufgabe verteilen.
Bei allen Fällen muss am Ende eine einzelne Liste der Schätzungen entstehen. Dadurch
erhält man Diskussionssto, der nicht unterbunden werden soll, sondern durch den Moderator
eektiv geleitet wird. Er achtet auf eine ausgewogene Teamarbeit, bei der keine
Meinung unterdrückt oder bloÿgestellt wird.
3.5.2. Anforderungen an der Projektleitung
Für jedes Projekt ist ein Projektleiter verantwortlich. Sein Talent sollte nicht unbedingt in
Klärung groÿen technischen Fragen liegen. Für diesen Posten sind andere Talente gefragt.
• Umgang mit der Komplexität; der Projektleiter muss wissen, was zum Projektauftrag
gehört und was nicht. Er legt fest welche Aspekte berücksichtigt werden und
welche Auswirkungen bei der Arbeit entstehen können.
• Gestaltung innovativer Prozesse; der Projektleiter sorgt ebenfalls für ein kreatives
Arbeitsklima. Er sorgt für Fairness unter den Teammitgliedern. Lobt, motiviert und
übt konstruktive Kritik. Auÿerdem unterstützt er das Team mit der Verfügungstellung
von Informationsquellen zur Problemlösungen.
• Umgang mit Unsicherheit; er hilft Unsicherheiten zu entschärfen durch Weitergabe
von Informationen, Gestaltung von Einführungen und der Erläuterung des Umganges
mit neuen Anforderungen. Er ist Ansprechpartner und Vertrauensperson
36

3.5. SCHÄTZUNG IM TEAM
aller Gruppenmitglieder. Sein Überblick über das Ganze ist gefragt. Daher ist regelmäÿiges
Feedback zwischen ihn und den Gruppenmitgliedern eine elementarer
Bestandteil.
• Einführung von einer speziellen Projektorganisation; um ein Chaos zu vermeiden
sollte eine gezielte Organisationsstruktur eingeführt werden. Solche Strukturen können
aus Arbeits- und Spielregeln für das Team bestehen. Je kleiner das Team, desto
demokratischer wird alles gehandhabt. Bei groÿen Gruppen muss immer wieder der
Projektleiter die letzte Entscheidungsinstanz darstellen.
• Leitung eines interdisziplinären Teams; man muss ein Team formen und stärken.
Hier ist wichtig Rollen zu verteilen und Synergieeekte zu erzeugen.
• Umgang mit Struktur und Kreativität; schwierig aber wichtig ist es immer die richtige
Waage zwischen Kreativität und Struktur zu erhalten. Das eine fördert die Ideen,
dass andere verhindert den Chaos.
• Vertretung nach Auÿen; er tritt mit relevanten Personen auÿerhalb des Teams in
Kontakt um nötige Informationen zu besorgen oder die Werbetrommel für die Notwendigkeit
seines Projektes zu drehen.
3.5.3. Teamentwicklung
ein starkes und gutes Team entwickelt sich nicht aus Zufall oder sogar sofort. Auf dem
Weg zu DEM Team werden einige Konikte zu lösen sein. Man kann die Entwicklung
eines Teams in vier Phasen aufteilen.
1. Formingphase; in dieser Testphase lernen sich Teammitglieder kennen. Die Leute
sind höich zueinander. Das ist der richtig Zeitpunkt, um die Rollen zu verteilen,
Teilaufgaben und Arbeitsmethoden zu bestimmen.
2. Stormingphase; nachdem man sich oberächlich kennen gelernt hat, folgt eine Phase
der oenen Konikte, Konfrontationen und Turbulenzen. Jeder will sich gegenüber
den Anderen beweisen. Status und Rollen werden neu verteilt.
3. Normingphase; nun sind die Beziehungsfragen geklärt. Es geht um Sachfragen (Aufgabenverteilung,
Arbeitsmethoden und Spielregeln), die endgültig bestimmt werden.
Kooperation ist die Folge.
4. Performingphase; die Basis ist geschaen. Alle Rollen und Aufgaben verteilt und
aller persönliche Probleme geklärt. Ab jetzt beginnt das groÿe Schaen.
3.5.4. Mögliche Gestaltung eines Teamtres
Im Vorfeld erstellt der Projektleiter (oder die Personen, die für dieses Treen zuständig
ist) eine Tagesordnung. Sie gilt als Arbeitsgrundlage für das Treen. Am Anfang sollten
37

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
die wichtigsten Punkte bearbeitet werden und erst am Ende kommt die leichte Kost. Dabei
muss man aber immer auf den logischen Aufbau achten. Danach folgt die Einladung
mit der Tagesordnung. In der Einladung steht neben Ort, Zeit und Raum auch welche
Informationen benötigt werden oder Vorwissen verlangt wird. Allen sollte während der
Sitzung die Tagesordnung immer gegenwärtig sein. Am Anfang wird die Tagesordnung
noch mal vorgestellt und ein Protokollführer ernannt. Die Gesprächsleitung wird durch
einen Moderator übernommen. Dieser legt mit der Gruppe die Regeln der Gesprächsführung
fest und achtet auf ihrer Einhaltung. Er achtet auf Fairness und darauf das sich
möglichst alle einbringen. Zwischenergebnisse innerhalb der Sitzung werden für alle klar
sichtbar notiert. Das Protokoll sollte allen anschlieÿlich zugänglich gemacht werden.
3.6. Projektplan und Mitarbeitereinsatz
3.6.1. Projektplan
Der Projektplan ...
• legt Beginn, Ende und Reihenfolge der Tätigkeiten im Projekt fest
• deniert, wer wann was liefert
• zeigt Abhängigkeiten
• ist allgemein verständlich (mit einem Blick weiÿ jeder was los ist)
• unterstützt Abstimmungen (jeder erkennt mit wem er sich absprechen muss)
Der Projektplan wird aus der Aufwandsschätzung abgeleitet. Üblicherweise wird die Schätzung
in ein Gantt-Chart (bestimmte Form eines Projektplans) übertragen.
Der Gantt-Chart besteht aus horizontalen Balken. Jeder Balken repräsentiert den Verlauf
einer Tätigkeit mit dessen Anfang und Ende. Ebenfalls wird in einem Gantt-Chart
die Reihenfolge der Tätigkeiten ersichttlich und die dann beteiligten Mitarbeiter. Diese
Darstellungsmethode stammt von Henry L. Gantt (1917 entwickelt).
38

3.6. PROJEKTPLAN UND MITARBEITEREINSATZ
Abbildung 3.1.: Variante eines Gantt-Charts
Bevor man jedoch die Aufwandsschätzung so einfach in einem Projektplan ummünzt,
muss man noch einige Punkte beachten. Das sichert die Qualität des Projektplans.
• Bevor die Reihenfolge der Tätigkeiten festgelegt werden, sollte der Mitarbeitereinsatz,
die Zusammenarbeit und die Übergabepunkte feststehen.
• Die Abhängigkeiten sollten deniert sein.
• Der Projektplan darf nicht zu detailliert sein, um die Übersichtlichkeit zu behalten.
Aber wichtige Punkte (wie Meilensteine) sollten deutlich ersichtlich sein.
Zu diesen Punkten erfahren in den nächsten Kapiteln weiter erläutert.
3.6.2. Mitarbeitereinsatz
Wie öfter schon erwähnt können Abhängigkeiten zwischen den Tätigkeiten existieren.
Wenn ja, müssen diese sequentiell abgearbeitet werden. Wenn keine Abhängigkeiten zwischen
den Aufgaben bestehen, dann können diese auch parallel abgearbeitet werden. Daher
muss immer die Abhängigkeit zwischen zwei Tätigkeiten analysiert werden. Durch
die richtige Mischung aus paralleler und sequentieller Arbeit erhält man eine qualitative
Arbeit in einem vernünftigen Zeitrahmen abzuliefern.
Dabei müssen aber nicht nur Abhängigkeiten erkannt werden. Sondern man muss auch
die Leute auf ihre Arbeit vorbereiten. Es sollten zum Beispiel keine harte Übergabepunkte
entstehen. Wenn sich ein Mitarbeiter erst mit seiner Arbeit beschäftigt, nachdem er sie
von seinem Vorgänger abgeliefert bekommt, dann ist was schief gelaufen. Bis er sich eingearbeitet
hat, ist schon wieder einige Zeit verloren. Um das zu verhindern, müssen die
Leute schon vor der Übergabe sich mit ihrer Arbeit beschäftigen oder involviert werden.
Denn jede Disziplin muss rechtzeitig erfahren, welche Einschränkungen und Anforderungen
sie von den anderen erhält. Dafür ist wiederum der Projektleiter zuständig um das
zu gewährleisten.
39

KAPITEL 3. PLANUNG VON WEB-PROJEKTEN
Zu Beginn des Projektes ist auch empfehlenswert zunächst nur die erfahrenen Leute einzusetzen
(Bsp. Bei der Ist-Beschreibung und Pichtenheft). Der Grund liegt im fachlichen
Anspruch und der Verantwortung der Aufgabe.
Der Gesamteinsatz der Mitarbeiter kann schlieÿlich so aussehen.
• Projektvorbereitung, Pichtenheft, Ist-Beschreibung => Kernteam mit erfahrenen
Leuten
• Grobkonzept => Qualizierte Spezialisten
• Design, IT => Volles Team
Abhängigkeitsanalyse
Bei der Abhängigkeitsanalyse wird festgestellt, was für Voraussetzungen bei jeder Tätigkeit
erfüllt sein müssen um diese angehen zu können. Die Voraussetzungen könnten
sein:
• Ergebnisse anderer Tätigkeiten werden benötigt
• Mitwirkung der Kunden
• Ressourcen, die man benötigt
• Zugrie auf Schnittstellen etc.
Nur so kann die richtige Reihenfolge erkannt werden. Wodurch wiederum der "kritische
Pfadërsichtlich wird. Der kritische Pfad ist die Abfolge derjenigen aufeinander folgenden
Tätigkeiten, welche beginnend beim Projektstart und endend bei Projektende die Dauer
des Projektes bestimmen. Das Hervorheben des kritischen Pfades im Projektplan erlaubt
Maÿnahmen zur Verkürzung der Projektdauer. Beispielsweise erkennt man an welchen
Stellen sinnvoll ist mehr Leute einzusetzen.
3.7. Iteratives Vorgehen
Mit Iteration in Projekten, meint man das wiederholte Durchlaufen von Projektschritten.
Dabei können einzelne Schritte (wie die Testphase) mehrmals direkt wiederholt werden,
oder eine Abfolge von Schritten wird erneut durchgangen.
Die Iteration kann unterschiedliche Formen annehmen.
Ein Prototyp dient als Versuchsobjekt, das bereits wesentliche Merkmale des Endergebnisses
aufweist. Das Ziel ist es, vorab kritische Aspekte (Machbarkeit usw.) zu erkennen.
Auÿerdem kann der Kunde das bisherige Ergebnis mit seinen Vorstellungen abgleichen
und wenn nötig korrigieren. In allen Phasen des Projektes können Implementierungen
erfolgen, um mögliche Lösungen zu testen.
40

3.8. FAZIT
Eine Vorab-Lösung kann auch erstmal durch bestimmte Iterationsschritte erfolgen.
Nachdem ein Pichtenheft oder ein Grobkonzept vorliegt, werden die Schritte Feinkonzeption,
Implementierung und Test wiederholt durchlaufen. Dabei werden Teile der Lösung
hintereinander entwickelt oder in mehreren Iterationsschritten schrittweise ausgebaut. Das
verfolgt den Zweck, bereits früh eine nutzbare Teillösung (gut für den Kunden) zu haben.
Durch ein schnellen Durchlauf der Schritte kann ebenfalls der Aufwand besser geschätzt
werden. Auÿerdem kann von Iterationsschritt zu Iterationsschritt die gemachten Erfahrungen
hilfreich angewendet werden.
Beim Prinzip des Pilotprojekt wird eine eingeschränkte Version entwickelt. Die dient
dann zum Einsatz in einem Testbereich. Dadurch können Erfahrungen gesammelt werden
bei geringerem Schadensrisiko. Nach einer Analyse der Testphase wird dann das Projekt
weiterentwickelt.
Oft wird die Iteration mit dem Wasserfallmodel kombiniert (oder umgekehrt). Es ist von
der Teilaufgabe abhängig, welches Prinzip man verfolgt.
Das Problem bei der Iteration ist die Erschwerung der Aufwandsschätzung. Wenn sich die
Iteration auf inhaltliche Erkenntnisse beschränkt, dann ist eine früheAbschätzung möglich.
Jedoch wenn erst nach den ersten Schritten der Ablauf erkennbar wird, kann man den
Projektplan für die weiteren Schritte nur nach und nach erstellen. Bei der Erstellung eines
Angebots, darf nur der planbare Bereich berücksichtigt werden. Oder man integriert noch
ein Risikoaufschlag.
3.8. Fazit
Am Ende kann man sagen, dass ein erfolgreicher Projektverlauf von einer guten Planung
abhängt. Und diese Planung hängt wiederum von einem starken Team, aber hauptsichtlich
von den Projektleiter ab. Er ist für alles Verantwortlich. Das Team erzielt wohl das
Ergebnis, aber er gibt vor wie es zu erreichen ist.
41

4. Softwarearchitektur und
Konzeption der
Anwendungsschicht
4.1. Einleitung
Bei der Entwicklung von Informationssystemen hat sich in den letzten Jahren ein klarer
Trend zu Multi-Schichten-Architekturen abgezeichnet [Has00]. Ihre Vorteile gegenüber
monolithischen Systemen ohne scharfe Trennung zwischen Schichten wie Datenhaltung
und -beschaung, Geschäftslogik und Präsentation liegen vor allem in besserer Erweiterbarkeit,
Wartbarkeit und Skalierbarkeit. In den Entwicklungsprozessen solcher Softwaresysteme
ist in immer stärkerem Maÿe konzeptionelles Denken und Arbeiten im Gegensatz
zu Programmieren im Kleinen gefragt, was zwar der Notwendigkeit des letzten keinen
Abbruch tut, allerdings dessen Ezienz deutlich erhöhen kann und vor allem zu einer höherer
Qualität des Ergebnisses sowohl der Software selbst als auch der dazugehörigen
Dokumentation führt.
Die erstarkende Bedeutung von Softwarearchitektur und ihrer Konzeption kommt auch
im J2EE-Applikationsmodell [Sun05] zum Ausdruck, auf das sich die vorliegende Arbeit
aufgrund ihres in die Projektgruppe eingebetteten Kontextes häug fokussiert. So stellen
viele der für PGPortal relevanten J2EE-Technologien nicht nur reine APIs zur Nutzung
bestimmter Funktionalitäten zur Verfügung, sondern geben oft auch eine bestimmte Architektur
vor[DH03].
In Kapitel 4.2 dieser Arbeit werden zunächst einige grundlegende, die Softwarearchitektur
betreende Aspekte vorgestellt. Kapitel 4.3 stellt einige zentrale J2EE-Architekturkonzepte
der Anwendungsschicht vor, während Kapitel 4.4 ausgewählte Entwurfsmuster für deren
möglichst optimale Integration in konkrete Informationssysteme beschreibt. Mit Kapitel
4.5 folgen schlieÿlich Fazit und Ausblick.
4.2. Softwarearchitektur und Komponenten
Zur Klärung des Softwarearchitektur-Begris hier zunächst ein Auszug aus IEEE 1471-
2000 [MEH01]:
Architecture: The fundamental organization of a system embodied in its components, their
relationships to each other, and to the environment, and the principles guiding its design
and evolution.
42

4.3. KONZEPTE UND TECHNOLOGIEN
Zentral ist dabei vor allem der Komponentenbegri. Da über die genaue Denition dieses
Begris in der Fachwelt noch keine Einigkeit herrscht soll hier lediglich eine grobe
Beschreibung stattnden, und zwar insbesondere eine solche, die für die anschlieÿenden
konkreten Technologiebetrachtungen passend erscheint.
Unter einer Komponente versteht man im Software Engineering eine in sich abgeschlossene
Entität, die eine bestimmte Aufgabe in einem Gesamtsystem erfüllt. Dazu stellt sie über
eine präzise denierte Schnittstelle ihre Dienste anderen Komponenten zur Verfügung.
Komponenten sollten untereinander lose gekoppelt (losely coupled), d.h. so wenig wie
möglich auf die spezielle Arbeitsweise der jeweils anderen Komponenten spezialisiert sein.
Auf diese Weise können die Komponenten weitestgehend autonom agieren und die Aspekte
Wartbarkeit und Wiederverwendung beides Grundprinzipien im Software Engineering
werden äuÿerst positiv beeinuÿt.
Häug auch als essentiell für eine Komponente angesehen wird neben der schon erwähnten
Schnittstellendenition ein ebenfalls nach auÿen angebotener Deskriptor,
der diverse wichtige Informationen über sie enthält. Dazu gehören etwa Abhängigkeitsinformationen,
benötigte Ressourcen, Parameter für Laufzeitumgebungen und dergleichen
mehr. Anhand solcher Informationen wird es dann auch möglich, Komponenten semiautomatisch
in laufende Systeme zu integrieren, was in modernen Umgebungen immer
häuger zur Anforderung wird.
Die Architektur der Anwendungsschicht heutiger Informationssysteme setzt in breitem
Umfang auf den Komponentengedanken auf, was verschiedene Gründe hat. Moderne Komponentenframeworks
erlauben eine konkrete und elegante Umsetzung dieses Konzepts mit
objektorientierten Mitteln und bieten dabei eine sehr breite Middleware-Unterstützung für
viele wiederkehrende Problembereiche, etwa Transaktionen, Persistenz oder Verteiltheit.
Diese Aspekte sind ohne Middlewareunterstützung in vielen Bereichen unter den jeweils
gegebenen Voraussetzungen gar nicht mehr zu realisieren. Auÿerdem erlaubt die komponentenbasierte
Softwareentwicklung insbesondere zu Beginn der Projektphase ein stark
Top-Down-orientiertes Vorgehen, was Managementvorgaben zumindest zum Schein
zunächst eher entgegenkommt als andere Vorgehensmodelle.
4.3. Konzepte und Technologien
4.3.1. J2EE Multi-Schichten-Architektur
Abbildung 4.1 gibt einen Überblick über das allgemeine Applikationsmodell von J2EE-
Systemen. Von besonderer Bedeutung für diese Arbeit ist dabei die Schicht der Geschäftslogik
oder auch Anwendungsschicht.
4.3.2. Technologien der Anwendungsschicht
Die Geschäftslogik wird in einer J2EE-Anwendung in der Regel durch Enterprise Java
Beans (EJBs) umgesetzt. Es handelt sich dabei um standardisierte, in der Programmiersprache
Java implementierte, serverseitige Komponenten, die im Kontext einer speziellen
43

KAPITEL 4. SOFTWAREARCHITEKTUR UND KONZEPTION DER ANWENDUNGSSCHICHT
Abbildung 4.1.: J2EE Enterprise Application Model; Quelle: Sun Microsystems ([Sun05])
Laufzeitumgebung, dem EJB-Container, laufen. Dieser ist Teil eines J2EE-Applikationsservers
und verwaltet die EJB-Komponenten.
Die EJB 2.0 Spezikation [Sun04] kennt drei Arten von EJB-Komponenten: Entity Beans,
Session Beans und Message-Driven Beans. Diese drei Subtypen von Komponenten der
Anwendungsschicht von J2EE-Systemen werden weiter unten jeweils näher beschrieben.
Enterprise Java Beans
Kommunikation zwischen und mit EJBs funktioniert nicht durch eine direkte Instanziierung
der Bean-Klassen sondern im Allgemeinen über Java Remote Method Invocation
über das Internet Inter-ORB Protocol Java RMI-IIOP 1 . Die Verwaltung der tatsächlichen
Instanzen, die das Interface javax.ejb.EJBObject implementierende Objekte darstellen,
ist dabei Aufgabe des Applikationsservers.
Clients einer EJB-Komponente können z. B. Portlets, Servlets oder Applets sein, aber
auch wieder andere EJBs. Sie kommunizieren mit der Komponente, indem sie mithilfe
des Java Naming and Directory Service JNDI 2 an eine Referenz auf ein spezielles Ob-
1
Documentation, Java RMI over IIOP: http://java.sun.com/products/rmi-iiop/ (Abruf: 16. April
2006)
2
Core Java, Java Naming and Directory Interface: http://java.sun.com/products/jndi/ (Abruf: 16.
April 2006)
44

4.3. KONZEPTE UND TECHNOLOGIEN
jekt gelangen. Dieses Objekt, welches das Factory Entwurfsmuster umsetzt und in der
EJB-Spezikation home object genannt wird, implementiert ein bestimmtes Interface,
das home interface. Mit dem home interface legt der Entwickler der EJB-Komponenten
fest, auf welche Weise das EJB-Objekt im Applikationsserver initialisiert werden soll. Bei
Session Beans besteht das home interface häug nur aus einer einzigen, parameterlosen
Factory-Methode create(). Da EJB Objekte von Entity Beans eine Sicht auf die darunterliegende
Datenbank repräsentieren, bieten ihre home interfaces dagegen zumindest
eine Methode zum Aunden dieser Daten an: findByPrimaryKey. In der Regel gibt es
hier weitere solcher sogenannten nder Methoden sowie Methoden zum Erzeugen von
neuen Datensätzen.
Die Methoden des home interface haben gemein, dass sie von Ausnahmen abgesehen
die Objekte zurückliefern, die das remote interface der EJB-Komponente implementieren.
Das remote interface deniert die eigentlichen Methoden, die die EJB-Komponente
den Clients anbietet. Bei Entity Beans sind dies in erster Linie get und set Methoden,
die für das Lesen und Schreiben von persistenten Daten benutzt werden. Session Beans
dagegen führen hier die Signaturen ihrer sog. business methods auf, bei denen es sich
um anwendungsfallspezische Methoden handelt, die in der Regel einen bestimmten Geschäftsprozess
abbilden und jeweils eine Nutzeranfrage bedienen.
Dieses Zusammenspiel aus home interface, remote interface und eigentlicher Bean-Klasse
sowie RMI-IIOP und JNDI bietet eine starke Entkopplung zwischen der EJB-Komponente
und ihren Clients und ermöglicht Transparenz bei der Kommunikation zwischen verschiedenen
Java Virtual Machines, die auf verschiedenen Rechnern sowohl in lokalen Netzen
als auch im Internet laufen können.
Wenn allerdings die Verteiltheit der Komponenten kein relevantes Kriterium ist, was insbesondere
häug bei Anwendungen der Fall ist, bei denen Entity Beans und auf sie zugreifende
Session Beans im gleichen Prozess laufen sollen, wird durch diesen Mechanismus
ein erheblicher, vermeidbarer Overhead erzeugt. Gerade das durch RMI-IIOP verursachte
Vor- und Nachbereiten von Übergabeparametern und Rückgabewerten für den Versand
über ein Netzwerk, das sog. (un-) marshalling, sorgt in diesem Fall für starke Einbuÿen
bei der Performanz. Aus diesem Grund wurden mit der EJB 2.0 Spezikation analog zu
home interface und remote interface das local home interface und das local interface eingeführt.
Das JNDI liefert dann statt einer Referenz zu einem entfernten Objekt eine
lokale Referenz, wodurch der Overhead stark verringert wird.
Eine EJB-Komponente kann gleichzeitig sowohl ein local interface als hochperformante
Schnittstelle innerhalb eines Prozesses als auch ein remote interface für den Fernzugri
anbieten.
Neben einem Deployment-Deskriptor, der diverse Informationen insbesondere auch
solche, die für das korrekte Deployment für den Applikationsserver notwendig sind
über die Komponente in XML-Syntax beinhaltet, bestehen EJB-Komponenten also aus
folgenden Bestandteilen:
1. Dem Home Interface, abgeleitet von javax.ejb.EJBHome
2. Dem Remote Interface, abgeleitet von javax.ejb.EJBObject
45

KAPITEL 4. SOFTWAREARCHITEKTUR UND KONZEPTION DER ANWENDUNGSSCHICHT
3. Dem Local Home Interface, abgeleitet von javax.ejb.EJBLocalHome
4. Dem Local Interface, abgeleitet von javax.ejb.EJBLocalObject
5. Der Bean-Klasse, abgeleitet je nach Art der EJB-Komponente von javax.ejb-
.EntityBean oder javax.ejb.SessionBean
Dies führt bereits bei relativ wenigen EJBs innerhalb einer Anwendung zu einer groÿen
Anzahl an Java-Dateien. Zugunsten von Übersichtlichkeit und Einheitlichkeit werden die
EJB-Bestandteile daher konform zu den J2EE Naming Conventions for Enterprise Applications
3 benannt. Abbildung 4.2 zeigt die Zusammenhänge zwischen den erläuterten
EJB-Bestandteilen in UML-Syntax.
Abbildung 4.2.: Bestandteile einer Session Bean SearchBean; die Assoziationen zwischen
der Bean-Klasse und den Interfaces sind nicht in Java-Syntax sondern
ausschlieÿlich mit der EJB-Spezikation begründet. Entsprechende Fehler
treten infolgedessen erst beim Deployment zutage und führen dann zu
einer EJB Specication Violation.
Entity Beans
Für den Zugri auf die Datenhaltungsschicht sind Entity Beans vorgesehen. Sie modellieren
gemeinsam das persistente Datenmodell des Systems, wobei in der Regel eine En-
3 http://java.sun.com/blueprints/code/namingconventions.html (Abruf: 16. April 2006)
46

4.3. KONZEPTE UND TECHNOLOGIEN
tity Bean jeweils eine Entität abdeckt. Es kann hier zwischen Bean Managed Persistence
(BMP) und Container Managed Persistence unterschieden werden.
Im Falle von BMP erfolgt die Persistenzsicherung durch die Entity Bean selbst, d. h. der
Entwickler muss in der Regel mithilfe von Aufrufen der Java Database Connectivity
(JDBC 4 ) API dafür Sorge tragen, dass die Daten einem DBMS übergeben bzw. aus
selbigem bezogen werden werden.
Bei CMP erfolgen die persistenzgewährleistenden Operationen durch den EJB-Container,
spezieller durch dessen CMP-Engine. Der Entwickler speziziert dazu die zu persistierenden
Datenfelder sowie verschiedene notwendige Zusatzinformationen (z. B. über den
jeweiligen Primärschlüssel) in speziellen XML-Deployment-Deskriptoren. Auÿerdem stellt
er eine abstrakte Java-Klasse bereit, die Signaturen der Methoden enthält, über die auf die
Daten zugegrien werden soll. Der Container erzeugt daraus automatisiert eine konkrete
Implementierung der Entity Bean Klasse. Eine detaillierte Diskussion der Besonderheiten,
Vorteile und Nachteile der CMP-Technologie liegt auÿerhalb des Themenbereichs dieser
Arbeit. Es sei hier lediglich angemerkt, dass aus softwarearchitektonischer Sicht CMP
im Allgemeinen BMP vorzuziehen ist, da sie eine Entkopplung vom zugrunde liegenden
DBMS bietet.
Mit CMP eng verknüpft sind Container Managed Relationships (CMR). Durch den Einsatz
dieser Technologie, mit der die Beziehungen zwischen Entity Beans unterstützt durch
den EJB-Container modelliert werden können, kann ebenso wie durch CMP der Implementierungsaufwand
verringert und die interne Qualität der Software erhöht werden. Wie
auch bei CMP wird dazu das gewünschte Verhalten gröÿtenteils deklarativ durch Einträge
in Deployment-Deskriptoren festgelegt. So kann beispielsweise eine 1..n-Beziehung
zwischen zwei Entitäten deklariert werden. Die Entity Bean der 1-Seite kann dadurch
sehr einfach um die Möglichkeit erweitert werden, ausgehend von ihr alle zugeordneten
Daten der n-Seite zu erhalten. Ebenso kann die Entity Bean der n-Seite durch ein solches
CMR-Feld in die Lage versetzt werden, die zugeordneten Daten der 1-Seite der Beziehung
anzubieten. Auf Datenbank-Ebene sorgt dann der Container dafür, dass die entsprechende
Tabelle eine Fremdschlüssel-Spalte erhält. Auch die notwendigen SQL-Abfragen
im Beispiel etwa mit einer geeigneten JOIN-Operation werden automatisch durch den
Container generiert. Eine Einschränkung diese Technologie ist, dass nur das local interface
einer Entity Bean über CMR-Felder verfügen kann, nicht aber das remote interface.
Session Beans
Während Entity Beans, die als Schnittstelle der Geschäftslogik zur darunter liegenden Datenhaltungsschicht
gesehen werden können, den Zugri auf das Datenmodell in objektorientierter
Art und Weise anbieten, modellieren Session Beans die eigentliche Geschäftslogik
des Systems. Ihre Instanzen bedienen also jeweils die Anfragen eines bestimmten Clients,
der durch den Aufruf der zur Verfügung gestellten Methoden der business methods
auf das System zugreift. Die Session Beans ihrerseits greifen bei der Bearbeitung dieser
Nutzeranfragen auf die Entity Beans zu.
4 http://java.sun.com/products/jdbc/ (Abruf: 16. April 2006)
47

KAPITEL 4. SOFTWAREARCHITEKTUR UND KONZEPTION DER ANWENDUNGSSCHICHT
Es gibt zwei verschiedene Arten von Session Beans: Zustandslose (Stateless Session Beans)
und zustandsbehaftete (Stateful Session Beans). Die Entscheidung für eine dieser beiden
Unterarten ist eine wichtiger Schritt im Architekturentwurf.
Bei der Diskussion im Software Engineering insbesondere im Umfeld von Enterprise
Java hat sich die Ansicht durchgesetzt, dass Geschäftslogik nach Möglichkeit zustandslos,
d.h. unter Einsatz von Stateless Session Beans implementiert werden sollte. Bei der
Implementierung von Stateless Session Beans muss darauf geachtet werden, dass serverseitig
eine Instanz (EJBObject) nicht an einen Client gebunden ist, sondern durch das
durch den Applikationsserver durchgeführte instance pooling für Anfragen von verschiedenen
Clients wiederverwendet wird. Zudem können die Instanzen jederzeit passiviert oder
auch komplett deaktiviert werden, wenn der Applikationsserver etwa nach einer Lastspitze
entscheidet, dass nun wieder weniger Instanzen ausreichen. Dies führt dazu, dass keine
anfragespezischen Daten in der Bean-Implementierungsklasse vorgehalten werden dürfen:
Alle für eine business method relevante Parameter müssen vom Client übergeben
werden. Der eigentliche Zustand des Systems für den Benutzer wird auf diese Weise vor
allem durch die Datenhaltungsschicht deniert und zum anderen Teil bei mehrschrittigen
Vorgängen durch die Präsentationsschicht, etwa in Form der HTTP-Session bei
webbasierten Applikationen. Die Anwendungsschicht selbst bleibt zustandsfrei.
In bestimmten Situationen kann es allerdings notwendig oder ratsam sein, die Geschäftslogik
doch mit einem Zustand auszustatten. Dies ist insbesondere dann der Fall, wenn
die einzelnen durch business methods modellierten Geschäftsvorgänge eine starke Abhängigkeit
voneinander aufweisen, die über eine folgt nach oder gehört zu Beziehung
hinausgehen. In solchen Fällen kann es sein, dass eine Umsetzung mit Stateless Session
Beans zu einer stark aufgeblähten Datenhaltungsschicht führen würde, da in diesem
Fall komplexe Zwischenzustände ebenfalls durch sie verwaltet werden müssen. Hier kann
die Anwendungsschicht mit Stateful Session Beans umgesetzt werden, die nicht den erläuterten
Einschränkungen von Stateless Session Beans unterliegen und damit für den
Entwickler eher POJOs 5 ähneln. Allerdings verleiten Stateful Session Beans aufgrund
dieser erweiterten Möglichkeiten leicht zu einer unsauberer Abgrenzung der Schichten
untereinander.
Message Driven Beans
Message Driven Beans, kurz MDBs, basieren auf dem Java Message Service 6 (JMS) und
sind diejenigen EJB-Komponenten die asynchrone Kommunikation durch Messaging ermöglichen.
Anders als Entity- und Session Beans verfügen MDBs nicht über Komponenteninterfaces.
Sie bestehen dagegen im Wesentlich aus einer Java-Klasse mit einer
public-Methode onMessage(), die durch den JMS angerufen wird, wenn die MDB eine
Nachricht erhalten soll.
MDBs werden häug zur Anbindung von externen Systemen eingesetzt, insbesondere bei
Legacy-Systemen.
5
Von Martin Fowler geprägter Begri der Plain Old Java Objects, also normale Java-Objekte von
höherwertigen Komponenten wie EJBs abgrenzt
6 http://java.sun.com/products/jms/ (Abruf: 16. April 2006
48

4.4. ENTWURFSMUSTER
4.4. Entwurfsmuster
Durch das EJB-Komponentenframework ist es möglich, vielen wiederkehrenden, potenziellen
Problemstellungen bei der Entwicklung komplexer Informationssysteme bereits
frühzeitig auf architektureller Ebene zu begegnen. Allerdings heiÿt der Einsatz von
EJB nicht, dass bereits eine gute Architektur vorgegeben wäre. Vielmehr müssen die gegebenen
Technologien mit Bedacht eingesetzt werden, so dass wirklich die gewünschte gute
Softwarequalität dabei herauskommt. Dabei haben sich für den EJB-Bereich eigene Entwurfsmuster
herauskristallisiert musterartige Verfahrensweise die zu guten Ergebnissen
führen und sich bereits mehrfach in der Praxis bewährt haben.
Zwei solcher Muster werden nun exemplarisch vorgestellt: Das Session-Façade-Muster und
Data-Transfer-Object (DTO-) Muster.
4.4.1. Session-Façade
Nach dem Session-Façade-Muster werden alle Aufrufe aus der Clientschicht an eine zentralisierte
Session-Façade gerichtet, siehe Abbildung 4.3. Direkte Zugrie auf Datenhaltungsobjekte
(in der Abbildung Entity Beans, es sind hier aber auch andere Technologien
denkbar) werden nicht zugelassen. Stattdessen werden entsprechende Aufrufe durch die
Session-Façade gekapselt.
Abbildung 4.3.: Session-Façade; Quelle: [Mar02]
Dieses Vorgehen hat zum einen den Vorteil, dass die Session-Façade als klar denierte,
zentralisierte Instanz für die gesamte Clientschicht die Anzahl der notwendigen Netzwerkzugrie
minimiert, die nach den Ausführungen unter 4.3.2 teuer sind als ideal wird bei
EJB oft ein RMI-IIOP Zugri pro Anwendungsfall angesehen. Zum anderen trennt ein
solches Vorgehen die Schichten deutlicher voneinander ab: Es gibt bei Durchsetzung einer
Session-Façade nur noch genau eine Stelle, an die Aufrufe getätigt werden können bzw.
müssen, etwa analog zu einem Bankschalter im Vergleich zum Supermarkt.
49

KAPITEL 4. SOFTWAREARCHITEKTUR UND KONZEPTION DER ANWENDUNGSSCHICHT
4.4.2. Data Transfer Objects
Es kommt oft vor, dass bestimmte anwendungsspezische Daten als Einheit über mindestens
eine Schicht hinweg weitergegeben müssen. In diesen Fällen ist es günstig sog.
Data Transfer Objects einzusetzen. Dabei handelt es sich um reine Datenhaltungsklassen
ohne jede Geschäftslogik. In Java werden DTOs typischerweise als JavaBeans implementiert,
sind serialisierbar und verfügen nicht zu verwechseln mit Geschäftslogik über
in der objektorientierten Programmierung übliche Operationen etwa zum Vergleich, zur
Gleichheit, zur Duplizierung und dergleichen mehr.
Gegenüber der Bereitsstellung der benötigten Datenfelder eines DTOs per einzelnem Methodenaufruf
hat das DTO-Muster wie auch das Session-Façade-Muster den Vorteil des
geringen Netzwerkoverheads.
4.5. Fazit und Ausblick
In J2EE-Systemen basiert die Anwendungsschicht in der Regel auf Enterprise JavaBeans
Technologie. Dazu existieren für den Datenzugri (Entity Beans) für die Geschäftslogik
(Session Beans) und die ansynchrone Anbindung externer Systeme jeweils eigene Subtypen,
die jeweils kurz vorgestellt wurden. Das J2EE-Applikationsmodell verfügt damit
sowohl über geeignete Werkzeuge, den hohen Anforderungen an moderne Informationssystemen
bereits auf architektureller Ebene gerecht zu werden, als auch über Unterstützung
bei konkreten Problemstellungen bei der Ausentwicklung der Komponenten durch die
Middleware.
Um Problemen bei der Entwicklung der Anwendungsschicht mit EJBs von vornherein
vorzubeugen und so eine gute Architektur zu erhalten und beizubehalten sind speziell auf
die EJB-Technologie ausgelegte Entwurfsmuster hilfreich. Zwei davon konnten im Kontext
dieser Arbeit vorgestellt werden. Für weitere sei auf [Mar02] 7 verwiesen.
Die J2EE-Technologien der Anwendungsschicht unterliegen einer steten Weiterentwicklung.
In der kommenden EJB-Version 3.0 etwa wurden zahlreiche tiefgreifende Änderungen
vorgenommen die gröÿtenteils Probleme mit der hier vorgestellten EJB-Version 2.0
bzw. 2.1 aufgreift. So werden etwa die Vielzahl der zu pegenden Interfaces ohne die Möglichkeit
von Compile-Zeit Überprüfungen, die nicht vorhandenen Testmöglichkeiten ohne
Applikationsserver und die über die Zeit unnötig kompliziert gewordenen Deployment
Deskriptoren in EJB3.0 gezielt adressiert.
7
Frei verfügbar als eBook unter
http://www.theserverside.com/books/wiley/EJBDesignPatterns/index.tss
(Abruf: 16. April 2006)
50

5. Entwurf und Implementierung
von Websystemen
5.1. Einleitung
Das World Wide Web ndet mit jedem Tag in immer mehr Bereichen des alltäglichen Lebens
Einzug. Angefangen von Wirtschaft und Industrie über Bildungs- und Gesundheitswesen
bis hin zu öentlicher Verwaltung und dem Freizeitsektor übt das World Wide Web
kurz Web einen starken Einuss auf unser aller Leben aus [GM01]. Die Hauptursache
für diese Allgegenwärtigkeit liegt in der Natur des Web selbst begründet: Komfortabler,
kostengünstiger und einheitlicher Zugri auf global verteilte Informationen, die von jedermann
in Form von Webseiten erstellt und weltweit Verfügbar gemacht werden können
[BL96].
Ursprünglich als reines Informationsmedium konzipiert, wo eine Website als eine Menge
von mehr oder weniger logisch zusammenhängender statischer Webseiten miteinander
verknüpft durch Verweise verstanden wurde, entwickelt sich das Web mit der Zeit immer
mehr zu einem Anwendungsmedium. Heutzutage sind moderne Web-Anwendungen
vollwertige und hoch komplexe Softwaresysteme. Eine aufwendige Präsentation und Aufbearbeitung
von groÿen Mengen an Informationen, die Anpassung an unterschiedliche
Benutzerbedürfnisse, komplexe Navigationsstrukturen oder die Berücksichtigung von beschränkten
Endgeräten, wie Handys oder PDAs, stellen nur einige der wachsenden Anforderungen
an moderne Web-Anwendungen dar.
Auf dem Weg von einfachen dokumentenzentrierten Websites über interaktive und transaktionale
Web-Anwendungen bis hin zu solchen, die ubiquitäre Informationen nutzen
und somit personalisierte Dienste abhängig von Ort und Zeit für eine Vielzahl von
Endgeräten möglich machen, nimmt auch die Komplexität dieser Web-Anwendungen zu.
Dieser stetig wachsende Anteil an Anwendungslogik und Software in Web-Anwendungen
verwischt die Grenze zwischen Web-Anwendungen und traditionellen Softwareprodukten
zunehmens. Einzig der Gebrauch von Web-spezischen Technologien und Standards machen
den Unterschied aus. Daher kann eine Web-Anwendung wie folgt deniert werden:
Eine Web-Anwendung ist ein Softwaresystem, das auf Spezikationen des
World Wide Web Consortium (W3C) beruht und Web-spezische Ressourcen
wie Inhalte und Dienste bereitstellt, die über eine Benutzerschnittstelle, den
Web-Browser, verwendet werden. [KPRR04]
Bedauerlicherweise ndet bei der Entwicklung von Web-Anwendungen kaum methodisches
und prozessorientiertes Vorgehen statt, um der wachsenden Komplexität Herr zu
51

KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG VON WEBSYSTEMEN
werden. Vielmehr fühlt man sich an die Praktiken der Softwareentwicklung der 60er Jahre
zurückerinnert, die damals zur Softwarekrise geführt haben. Heutzutage können einfache
Websites mit Hilfe von verschiedenen Werkzeuge, wie z. B. HTML-Editoren, auch
ohne entsprechendes Fachwissen erstellt werden, was zur Folge hat, dass zum einen der
Einsatz von teureren Fachkräften gescheut und zum anderen dem Layout mehr Gewicht
beigemessen wird als der internen Struktur. Die Entwicklung beruht zudem oftmals auf
den Erfahrungen einzelner Entwickler und zeichnet sich häug durch eine unzureichende
Dokumentation von getroenen Entwurfsentscheidungen und Implementierungsdetails
aus. Das alles hat zur Folge, dass die entwickelten Web-Anwendungen nur sehr schwer
einsetzbar und wartbar sind. Des Weiteren weisen sie oft erhebliche Qualitätsmängel in
Bezug auf Zuverlässigkeit, Leistungsfähigkeit, Skalierbarkeit und Benutzerfreundlichkeit
des Systems auf.
Es zeigt sich also, dass trotz der steigenden Komplexität der Web-Anwendungen systematisch
strukturierte Vorgehensweisen und detaillierte Spezikationen bei ihrer Entwicklung
oftmals nicht berücksichtigt werden.
5.2. Web Engineering
Die Disziplin des Web Engineering nimmt sich ähnlich dem Software Engineering nach
der Softwarekrise der oben genannten Probleme an, um eine erneute Krise zu vermeiden,
die aufgrund der Omnipräsenz des Web erheblich höhere Auswirkungen haben
könnte. Wie auch beim Software Engineering üblich betrachtet das Web Engineering den
gesamten Lebenszyklus einer Web-Anwendung, um mittels ingenieurmäÿiger Anwendung
wissenschaftlicher Erkenntnisse, Systeme entwickeln zu können, die korrekt, sicher, schnell
und kostengünstig sind. Eine Denition von Web Engineering kann daher wie folgt aussehen:
Web Engineering ist die Anwendung systematischer und quantizierbarer Ansätze
(Konzepte, Methoden, Techniken, Werkzeuge), um Anforderungsbeschreibung,
Entwurf, Implementierung, Test, Betrieb und Wartung qualitativ hochwertiger
Web-Anwendungen kosteneektiv durchführen zu können. Web Engineering
bedeutet auch die wissenschaftliche Disziplin, die sich mit der Erforschung
dieser Ansätze beschäftigt. [KPRR04]
Gemeinsamkeiten zu traditionellen Anwendungen lassen sich nicht von der Hand weisen.
Dennoch müssen aufgrund der speziellen Anforderungen und Eigenheiten von Web-
Anwendungen viele Konzepte und Methoden aus dem Bereich des Software Engineering
auf diese Besonderheiten angepasst, erweitert oder gänzlich neu entwickelt werden. Das
Web Engineering kann daher als eigenständiger Zweig des Software Engineering betrachtet
werden.
Die Grundprinzipien des Web Engineering lauten [DLWZ03]:
• Klar denierte Ziele und Anforderungen
52

5.3. ENTWURF VON WEB-ANWENDUNGEN
• Systematische Entwicklung in Phasen
• Sorgfältige Ausgestaltung dieser Phasen
• Kontinuierliche Überwachung des gesamten Entwicklungsprozesses
Die Einhaltung dieser Prinzipien ermöglicht dabei die Planbarkeit und Wiederholbarkeit
des Entwicklungsprozesses, eine kontinuierliche Weiterentwicklung, die Kostenreduktion
und Risikominimierung bei der Neuentwicklung und Wartung, eine allgemeine Qualitätssteigerung
sowie die Messbarkeit der Qualität von Ergebnissen der einzelnen Phasen.
5.3. Entwurf von Web-Anwendungen
Eine wesentliche Phase innerhalb des Web Engineering stellt die Entwurfsphase dar. Sie
schlieÿt sich direkt an die Phase der Spezikation des Websystems an, in der die Anforderungen
an das zu erstellende System analysiert werden. Die Grundlegende Aufgabe des
Entwurfs einer Web-Anwendung liegt dabei in der Konstruktion einer Systemarchitektur
auf der Basis der in der Anforderungsanalyse ermittelten Anforderungen. Dabei lassen
sich die folgenden Teilaufgaben identizieren [DLWZ03]:
• Auswahl von konkreten Technologien und Komponenten
• Erstellung von Diagrammen, Schemata und Pseudocodes, die die hard- und softwarebezogenen
Anforderungen berücksichtigen
• Beschreibung von Struktur und Verhalten der einzelnen Systemkomponenten
• Entwurf der Benutzungsoberäche und des Navigationsdesigns
• Integration vorhandener Systeme
In den zwei folgenden Unterkapiteln werden alternative Herangehensweisen beschrieben,
die zu einem Websystementwurf führen sollen. Da ist auf der einen Seite die modellgetriebene
Top-Down-Entwicklung und die technologiegetriebene Bottom-Up-Entwicklung auf
der anderen. Beide scheinen auf den ersten Blick im Widerspruch zueinander zu stehen.
Allerdings ist die Intention der technologiegetriebenen Herangehensweise, der modellgetriebenen
Variante einen ergänzenden, sehr exiblen Blickwickel gegenüber zu stellen.
Abgerundet wird dieses Kapitel durch eine Beschreibung möglicher Strategien zur Architekturbildung
von Web-Anwendungen.
5.3.1. Modellgetriebene Top-Down-Entwicklung
Eine der eigentlichen Realisierung vorausgehende Modellierung von Systemen wird in ingenieurwissenschaftlichen
Disziplinen mit groÿem Erfolg angewendet, um die Komplexität
des zu modellierenden Systems zu reduzieren. Durch die Dokumentation von Entwurfsentscheidungen
kann das allgemeine Verständnis erheblich gesteigert und durch die abstrakten,
allgemein verständlichen Modelle die Kommunikation innerhalb von Projektteams
53

KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG VON WEBSYSTEMEN
sowie auch zu Auftraggebern und Kunden erleichtert werden. Die Bereitstellung einer
im ausreichenden Maÿe detaillierten Spezikation des zu implementierenden Systems ist
dabei das Hauptziel der Modellierung. Als Ergebnis dieses Prozesses entstehen vereinfachende
und möglichst intuitive Modelle, die die relevanten Gesichtspunkte des Systems
verkörpern und für die weiteren Projektphasen herangezogen werden.
In der Informatik liegen die Wurzeln der Modellierung zum einen im Data Engineering
und zum anderen im Software Engineering. Während im Data Engineering das Hauptaugenmerk
auf der Strukturierung von Daten liegt, also die Modellierung von Informationseinheiten
und deren Beziehungen untereinander, legte das Software Engineering ursprünglich
seinen Fokus auf die operationalen Aspekte eines Systems. Als wohl bekanntestes
Modell aus dem Bereich des Data Engineering ist das Entity-Relationship-Modell
(siehe dazu [Che76]) zu nennen. Erst die objektorientierte Modellierung vereinigte beide
Bereiche, so dass sowohl die Struktur als auch das Verhalten gleichermaÿen berücksichtigt
wurden. Die Modellierungssprache UML (Unied Modelling Language) stellt dabei
den Quasi-Standard für die objektorientierte Modellierung dar. Sie unterscheidet verschiede
Diagrammarten, die die einzelnen Ebenen und Beziehungen auf Strukur- und
Verhaltenssicht abbilden (vgl. [Som01]). UML wird häug auch für den Entwurf von
Web-Anwendungen verwendet liefert aber aufgrund von web-spezischen Konzepten
oftmals nicht den gewünschten Erfolg, da es einige Besonderheiten bei der Modellierung
von Web-Anwendungen zu berücksichtigen gilt.
Die Grundlagen des Web Engineering können aus den Basiskonzepten von Data und
Software Engineering übernommen werden. Diese gilt es allerdings um einige Zusätze zu
erweitern, die eine Modellierung der web-spezischen Konzepte möglich machen. Webspezische
Konzepte, die in diesem Maÿe nicht in traditioneller Software vorkommen,
sind z. B. die hypertextuellen Verlinkungen, verschiedene Zugrisstrukturen oder eine
starke Personalisierung. Die Anforderungen an die Modellierung von Web-Anwendungen
lassen sich wie in Abbildung 5.1 dargestellt in vier Dimensionen gliedern. Diese vier Dimensionen
Ebenen, Aspekte, Phasen und Kontextualität sollen nun im folgenden kurz
erläutert werden, wobei auch jeweils eine kurze Abgrenzung zum herkömmlichen Software
Engineering vorgenommen wird (vgl. [KPRR04]).
Abbildung 5.1.: Anforderungen an die Modellierung von Web-Anwendungen [KPRR04]
Die gröÿte Dierenz zwischen Software Engineering und Web Engineering besteht in der
54

5.3. ENTWURF VON WEB-ANWENDUNGEN
ersten Dimension - den Ebenen. Das Software Engineering beschränkt sich auf die zwei
Ebenen der Anwendungslogik und der darauf aufsetzenden Benutzungsschnittstelle, wodurch
eine Kapselung des Was und des Wie erreicht wird. Diese zwei Ebenen reichen
bei der Modellierung von Web-Anwendungen nicht aus, da sowohl der Dokumentencharakter
des Content als auch die nicht-lineare Navigation einbezogen werden muss. Hier
werden im Allgemeinen drei Ebenen unterschieden. Die erste Ebene bildet der Content,
also die darzustellenden Informationen und die Anwendungslogik. Schwerpunkte auf dieser
Ebene sind Methoden der Datenmodellierung und der Eliminierung von Redundanzen.
Die zweite Ebene, der Hypertext, setzt sich mit der Gliederung des Content in Knoten
und den Verweisen zwischen diesen Knoten auseinander. Dabei können für einen Content
auch verschiedene Hypertext-Strukturen und Zugrismodelle integriert werden. Auf
diese Weise können eine Personalisierung und die Anforderungen von unterschiedlicher
Benutzergruppen bzw. an verschiedene Endgeräte leichter realisiert werden. Auch können
Informationen auf mehrere Knoten redundant verteilt werden, so dass sie über mehrere
Zugrispfade aundbar sind und eine Navigation ezienter gestaltet werden kann.
Wichtig ist auÿerdem die Verwendung von wiederkehrenden und intuitiv nutzbaren Navigationsmustern,
um eine Desorientierung des Benutzers zu vermeiden. Die dritte Ebene,
die Präsentation, hat die Gestaltung der Benutzungsoberäche zur Aufgabe. Schwerpunkte
auf dieser Ebene liegen neben der Schaung einer einheitlichen Präsentationsstruktur
der Seiten auf Aspekten zur Steigerung des Wiedererkennungseekts beim Nutzer. Die
Zielsetzungen der drei vorgestellten Ebenen sind durchaus unterschiedlich. Dennoch soll
eine Abbildung der Ebenen durch explizites Denieren von Abhängigkeiten aufeinander
möglich sein. Die Vorteile dieser logischen Trennung liegen aber auf der Hand. Neben der
Wiederverwendung einzelner Ebenen wird eine Modellevolution und eine Reduzierung
von Komplexität erzielt. Ein Austausch und exibler Einsatz der verschiedenen Ebenen
ist ebenso möglich. Je nach Intention der Web-Anwendung kann die Gewichtung der drei
Ebenen anders aussehen. Gilt es lediglich groÿe Mengen an Informationen und Daten per
Web zugänglich zu machen, so wird der Fokus auf der Modellierung der Content- und
Hypertext-Ebenen liegen. Anders sieht es bei präsentationslastigen Web-Anwendungen
aus, die ihren Schwerpunkt in der Ausgestaltung der Präsentationsebene haben werden.
Die zweite Dimension bilden die Aspekte Struktur und Verhalten. Wie auch beim herkömmlichen
Software Engineering zeichnet sich die Struktur durch die Objekte, deren
Attribute und ihre Beziehungen untereinander aus und das Verhalten durch die Funktionen
und Prozesse nur mit dem Unterschied, dass sowohl die Struktur als auch das
Verhalten für alle drei Ebenen des Web Engineering festgelegt werden müssen. Inwieweit
letztendlich Anteile an Struktur und Verhalten in den einzelnen drei Ebenen berücksichtigt
werden müssen, hängt von der Art der Web-Anwendung ab. So bedürfen hoch interaktive
Web-Anwendungen sicherlich einen höheren Modellierungsanteil im Verhaltensaspekt als
z. B. statische Web-Anwendungen.
Web-Anwendungen durchlaufen wie auch herkömmliche Software während des Entwicklungsprozesses
mehrere Phasen. Diese Phasen stellen die dritte Dimension der in
Abbildung 1 dargestellten Anforderungen dar und gliedern sich in Analyse, Entwurf und
Implementierung. Allerdings existiert für die Entwicklung von Web-Anwendungen noch
55

KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG VON WEBSYSTEMEN
kein Konsens über ein generelles Vorgehensmodell. Je nach Typ der zu erstellenden Web-
Anwendung kann entweder ein informationsgetriebenes oder ein präsentationsgetriebenes
Vorgehen von Vorteil sein. Sogar agiles Vorgehen, was der modellbasierten Entwicklung
in gewissem Sinne widerspricht, hat in manchen Fällen seine Vorzüge, wenn man bedenkt,
dass viele der so genannten Internettechnologien einer stetigen Weiterentwicklung
unterworfen sind und beinahe täglich neue hinzu kommen. Die modellbasierte Entwicklung
bringt aber zahlreiche Vorteile mit sich, wie eine gute Werkzeugunterstützung, die
Möglichkeit der automatischen Generierung von Prototypen und eine Nachhaltigkeit der
Lösungsidee.
Ergänzend zu den bisher erläuterten drei Dimensionen kommt für das Web Engineering
im Gegensatz zum Software Engineering noch eine vierte Dimension hinzu die Kontextualität.
Sie resultiert aus der Omnipräsenz des Web, der Vielzahl an unterschiedlichen
Endgeräten und dem Wunsch nach Personalisierung. Die Modellierung von Kontextinformationen
wirkt sich auf alle anderen Dimensionen aus, so dass sie als eigene Modellierungsdimension
betrachtet wird (vgl. [KPRR04]).
5.3.2. Technologiegetriebene Bottom-Up-Entwicklung
Das Design von Web-Anwendungen wird heutzutage in hohem Maÿe von den Spezikationen
und Limitationen bestimmter Implementierungs- und Internettechnologien sowie
deren Zusammenspiel geprägt. Beinahe täglich sprieÿen neue Technologien aus dem Boden,
die Web-Anwendungen neue und noch ungeahnte Möglichkeiten bieten können. Die
sich daraus ergebenen Anforderungen gilt es beim Entwurf von Web-Anwendungen, die
am Puls der Zeit liegen sollen, von den Entwicklern zu bewältigen. Die stetige Suche nach
neuen Technologien und Standards und der Wunsch zu deren exiblen Umsetzung in
Web-Anwendungen kann zu häugen tief greifenden Änderungen von Modellen und Vorgehensweisen
führen. Neue Architekturmuster oder Implementierungstechnologien sind
keine Seltenheit, so dass das technologiebewusste Design teilweise im Widerspruch zur
modellbasierten Entwicklung zu stehen scheint. Allerdings liefern neue Technologien die
in den meisten Fällen als Antwort auf neuartige oder steigende Anforderungen entstehen
oftmals bessere Möglichkeiten der Modellierung im Sinne einer Reduktion von Komplexität.
Somit kann das technologiebewusste Design also als Erweiterung der beschriebenen
modellgetriebenen Entwicklung in Richtung noch komplexerer und softwarelastigerer
Web-Anwendungen angesehen werden (vgl. [KPRR04]).
Die drei Designwurzeln für Web-Anwendungen liegen im Hypertext- und Informationsdesign
sowie im objektorientierten Softwaredesign. Jede für sich betrachtet, kann keine
befriedigende Lösung liefern - es sind spezielle Ansätze für Web-spezisches Design gefragt.
Allerdings ist das Gebiet noch sehr jung und es bendet sich noch vieles im Fluss,
so dass sich gute und bewährte Methoden, Prozesse, Notationen und Werkzeuge für den
Entwurf erst langsam durchsetzen müssen. Es kann aber die folgende Vorgehensweise
empfohlen werden.
Die Web-Anwendung sollte zunächst in drei logische Schichten gegliedert werden, die dann
jeweils nach demselben Prinzip in zwei Bereiche geteilt werden. Der erste Bereich stellt
56

5.3. ENTWURF VON WEB-ANWENDUNGEN
die Komponenten dar also insbesondere die Knoten der Web-Anwendung, wie z. B.
Medien, Softwarekomponenten oder Datenbankzugänge. Der zweite Bereich repräsentiert
die Anordnung dieser Komponenten in Geechte. Abbildung 5.2 verdeutlicht nochmals
die sechs entstehenden Teilaufgaben des Designs von Web-Anwendungen.
Abbildung 5.2.: Teilaufgaben des Designs von Web-Anwendungen [KPRR04]
Aus der Abbildung geht hervor, dass eine klare Unterscheidung zwischen der Präsentation
und Interaktion vorgenommen wird, so dass beide Aspekte jeweils eine separate Schicht
bilden. Diese Unterscheidung hat ihren Ursprung im Model-View-Controller-Konzept, wo
ebenfalls eine logische Trennung zwischen View und Controller vollzogen wird. Entsprechend
stellt die Funktionsschicht das Model dar.
Die Komponenten in der Präsentationsschicht repräsentieren die darzustellenden Inhalte
selbst bzw. deren Präsentation. Die Geechte in der Präsentationsschicht also das Zusammenspiel
aller Knoten, Links und Anker bringen als Teilaufgabe die Präsentation
der Navigationssituation mit sich. Wichtig auf dieser Ebene ist die Nutzung von Fachkompetenzen,
da Ästhetik und Selbsterklärbarkeit enorm wichtig für die Akzeptanz einer
Web-Anwendung sind. Daher empehlt es sich, die Hilfe von Fachleuten, wie Mediendesignern
und Ingenieuren, in Anspruch zu nehmen.
Die Teilaufgaben für Geechte und Komponenten in der Schicht der Interaktion lassen sich
als Navigation und Dialog bezeichnen. Für die Navigation, also einer geeigneten Führung
des Benutzers durch die Inhalte und Angebote der Web-Anwendung, können verschiedene
Ansätze umgesetzt werden. Sie kann z. B. hierarchisch, explorativ oder Software-gesteuert
sein und sich dynamisch an Benutzer- oder Domänenmodellen anpassen. Der Dialog meint
dagegen die konkrete Interaktion mit dem Benutzer über z. B. Formulare oder Applets.
Zur Umsetzung der Aufgaben dieser Schicht bedient man sich am besten der Methoden
und Werkzeuge des klassischen Hypertextdesigns.
Abhängig vom Typ der Web-Anwendung können die Teilaufgaben für die Funktionsschicht
sehr unterschiedlich ausfallen. Diese Schicht beinhaltet den eigentlichen Kern der Web-
Anwendung nämlich die Funktionalität. Bei den einfachen statischen Websites aus
der Anfangszeit des Web war diese Schicht zwar kaum von Bedeutung. Allerdings änderte
sich dieses mit wachsender Komplexität und höherem Software- und Funktionsumfang der
Web-Anwendungen. Die Komponenten auf dieser Ebene reichen von einfachen Informationssystemen
und Softwaremodulen bis hin zu Web-Komponenten und die Geechte gehen
vom transaktionsorientierten Workow bis hin zur Orchestrierung von verschiedenen
57

KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG VON WEBSYSTEMEN
Diensten und Web-Services, die hoch personalisierbare Web-Anwendungen ermöglichen.
Modellierungstechniken für diese Schicht ergeben sich aus dem klassischen Informationsund
Softwaredesign (vgl. [KPRR04]).
5.3.3. Strategien zur Architekturbildung
Bei der Entwicklung einer Systemarchitektur, wie auch bei deren konkreten Umsetzung
während der Implementierungsphase, können verschiedene grundlegende Strategien verfolgt
werden. Die vier grundsätzlichen Vorgehensweisen lauten Top-down, Bottom-up,
Hardest-rst und Trial-and-error und werden einander in Abbildung 5.3 schematisch gegenübergestellt.
Abbildung 5.3.: Vorgehensweisen beim Architekturentwurf [DLWZ03]
Die beiden wichtigsten Ansätze sind dabei der Top-down- und der Bottom-up-Ansatz.
Allerdings schlieÿen sich die vier im folgenden beschriebenen Vorgehensweisen nicht gegenseitig
aus, sondern können sich sogar ergänzen.
Bei der Top-down-Strategie ndet eine schrittweise Spezialisierung statt. Es wird mit einer
Gesamtsicht auf das System begonnen, ohne jedoch sofort alle Einzelheiten zu spezizieren.
Von dieser Gesamtsicht aus beginnend, wird das System dann sukzessive verfeinert
bis es komplett entworfen ist und alle zunächst nicht berücksichtigten Details speziziert
sind. Dieses Vorgehen bietet sich insbesondere für die modellgetriebene Entwicklung an.
Die Bottom-Up-Strategie verfährt komplementär hier ndet eine schrittweise Generalisierung
statt. Angefangen mit dem Entwurf einzelner Teilfunktionen werden diese nach
58

5.4. TECHNOLOGIEN UND STANDARDS DER IMPLEMENTIERUNG
und nach zu einem Gesamtsystem zusammengesetzt. Dieses Vorgehen bietet sich besonders
beim komponentenbasierten Entwurf an oder zur Zusammenstellung verschiedener
Web-Services. So können einzelne Komponenten oder Web-Services zu einem gröÿeren
Gesamtsystem zusammengebaut werden. Problematisch bei dieser Strategie ist, dass ein
lauähiges Gesamtsystem erst am Ende verfügbar ist.
Stellt sich vor dem Entwurf oder vor der Implementierung heraus, dass einige Komponenten
des zu erstellenden Systems komplexer und somit schwieriger umzusetzen sind als
andere, so kann nach der Hardest-rst-Strategie verfahren werden. Eine Zuerstbehandlung
der vermeintlich schwereren Bestandteile kann dann Rückschlüsse über die Systemausprägung
und Machbarkeit insgesamt erlauben. So kann frühzeitig entsprechend reagiert werden
und der Projektplan ggf. angepasst werden.
Hat man es mit vielen neuen Technologien und Standards zu tun, so dass noch keine
ausreichenden Kenntnisse über deren Tauglichkeit und Integrationsmöglichkeit zur Verfügung
stehen, so macht durchaus auch eine chaotisch wirkende Trial-and-error-Strategie
Sinn. Es bleibt gerade beim Entwurf von Web-Anwendungen oft nichts anderes übrig, als
durch eine wilde Experimentierphase Möglichkeiten und Potenziale neuartiger Technologien
auszuloten.
5.4. Technologien und Standards der Implementierung
Im Anschluss an die Phase des Entwurfs folgt die eigentliche Implementierung der Web-
Anwendung. Sie kann deniert werden als die Umsetzung der Entwurfsergebnisse in ein
programmierbares, auf spezieller Hardware abarbeitbares Websystem und vollzieht sich
in den Phasen der Kodierung, des Tests, der Integration und der Installation [DLWZ03].
Mit entscheidend für den Erfolg einer Web-Anwendung ist dabei die Auswahl der einzusetzenden
(Implementierungs-) Technologien. Um eine Technologie sinnvoll einsetzen
zu können, ist es wichtig, ihre Einsatzmöglichkeiten und Grenzen sowie ihre Vor- und
Nachteile kurz ihre Charakteristika zu kennen. Wie bereits erwähnt, handelt es sich
bei modernen Web-Anwendungen um hoch komplexe Systeme, die eine Vielzahl an unterschiedlichen
Technologien verwenden. Diese sind zum Teil stark miteinander verzahnt,
so dass z. B. Architekturentscheidungen auch tief greifende Technologievorgaben nach
sich ziehen können und umgekehrt. Von diesem Blickwinkel betrachtet, bedarf es also eines
umfassenden Technologieverständnisses, das über die Technologien an sich hinausgeht
und auch deren Zusammenspiel berücksichtigt und Architekturdesigns in Betracht zieht
[KPRR04].
Gegenüber dem herkömmlichen Software Engineering zeichnen sich die Implementierungstechnologien
des Web Engineering durch die Besonderheit aus, dass Web-Standards verwendet
werden. Die Technologien des Web können grob in clientseitige, serverseitige und
dokumentenspezische Technologien klassiziert werden. Aufgrund der Vielzahl an verschiedenen
Technologien und des sehr begrenzten Rahmens dieser Ausarbeitung kann nur
in aller Kürze auf einige Beispiele eingegangen werden.
Zu den clientseitigen Technologien zählen z. B. Plugins und Helper-Programme. Dabei
handelt es sich um Anwendungen, die die Funktionalität des Browsers insofern erweitern,
59

KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG VON WEBSYSTEMEN
als dass er in die Lage versetzt wird, auch speziellere Medientypen verarbeiten zu können.
Eine Möglichkeit ganze Programme im Browser ausführen zu lassen, stellt die Verwendung
von Java-Applets dar. Das sind in Java geschriebene Programme, die im Browser in
einer so genannten Sandbox ablaufen einem Sicherheitsmodell, das nur kontrollierte
Zugrie auf Systemressourcen erlaubt.
Die serverseitigen Technologien lassen sich in die Bereiche URI Handler und Web-Services
einordnen. URI Handler verarbeiten am Server eingehende HTTP-Requests und dienen
zur Auslieferung der angefragten Ressourcen. In diesen Bereich fallende Technologien sind
u. a. Server-Side-Includes (SSI), das Common Gateway Interface (CGI), Möglichkeiten des
Server-Side-Scripting, wie ASP, PHP oder Cold Fusion, genauso wie Servlets, Java Server
Pages (JSP) oder ASP.NET. Web-Services dagegen sind Softwarekomponenten, die Funktionalität
über denierte Schnittstellen zur Verfügung stellen. Die Grundlage dafür bilden
die Standards SOAP (Simple Object Access Protocol), WSDL (Web Service Description
Language) und UDDI (Universal Description, Discovery, and Integration). SOAP dient
dabei zur plattformunabhängigen Kommunikation, die Beschreibung der Funktionalität
eines Dienstes erfolgt über WSDL und das Publizieren von Web-Services ist über den
UDDI-Standard möglich.
Die Auswahl an dokumentenspezischen Technologien und Standards ist nahezu grenzenlos
und wächst stetig weiter. Die meisten dieser Standards werden vom World Wide
Web Consortium (W3C) [W3C] entwickelt und gepegt und basieren auf XML (eXtensible
Markup Language). Neben Standards zur Denition neuer XML-basierter Dokumententypen
(XML-Schema) und zur einfachen Transformation von einem standardisierten
Dokumententyp in einen anderen (XSLT: eXtensible Stylesheet Language Transformations)
können dort auch Standards zur Erweiterung und Vereinheitlichung von Style-Sheet-
Anwendungen (XSL: eXtensible Stylesheet Language) oder zum Traversieren eines XML-
Dokuments (XPath: XML Path Language) gefunden werden. Selbst zweidimensionale, interaktive
Graken können in XML beschrieben werden (SVG: Scalable Vector Graphics),
genauso wie ganze Präsentation dynamisch und individuell zusammengestellt gehandhabt
werden können (SMIL: Synchronized Multimedia Integration Language). Nicht
zuletzt können logische, semantische Beziehungen zwischen Ressourcen deniert werden
(RDF: Resource Description Framework). Eine vollständige Auistung aller aktuellen
W3C Recommendations und Working Drafts ist hier zu nden: http://www.w3.org/TR/.
5.5. Fazit
Das Bewusstsein für ein methodisches, modellgetriebenes Vorgehen bei der Entwicklung
von hoch komplexen Web-Anwendungen ist noch nicht in dem Maÿe gereift, wie man es
sich wünschen würde. Methoden und Notationssprachen zur Modellierung von Websystemen
haben sich bisher noch nicht dauerhaft durchsetzen können. Inwieweit sich solche
Methoden etablieren werden, ist dabei nicht zuletzt davon abhängig, wie sich die zugehörige
Werkzeugunterstützung entwickeln wird. Dabei wird besonders wichtig sein, dass
diese Werkzeuge neben der Notation auch den Entwicklungsprozess an sich systematisch
unterstützen. Trotz aller Berücksichtigung der Methodik sollte dennoch immer genügend
60

5.5. FAZIT
Raum für agile Vorgehensweise bleiben, um auf die sich stetig ändernden technologischen
Anforderungen des Web exibel und schnell reagieren zu können. In gleichem Maÿe gilt
es das Zusammenspiel einer modellbasierten Top-down-Modellierung mit einer Bottomup-Integration
vorhandener Dienste und Komponenten zu ermöglichen.
Auch für die zahlreichen Implementierungstechnologien ist es schwer vorauszusagen, welche
sich in der Zukunft durchsetzen werden und welche nicht. Die Basistechnologie XML
hat sicherlich zu einer starken Homogenisierung von heterogenen Umgebungen geführt,
aber selbst wieder eine Vielzahl neuer Standards, die auf XML basieren, mit sich gebracht.
Nicht alle werden sich durchsetzen können. Letztendlich gilt es auch hier, dass Wissen um
neue Technologien zu nutzen und es in disziplinierte Vorgehensweisen zu integrieren.
61

6. Einführung in Portale und
Portlets
6.1. Was sind Portale und warum nutzt man sie?
6.1.1. Historisches
Portale haben im Internet in den vergangenen Jahren immer mehr an Bedeutung gewonnen.
Man ndet sie inzwischen in sämtlichen Bereichen des Internets und sie dienen den
verschiedensten Zwecken. Begonnen hat die Entwicklung von Portalen bzw. seinen Vorg
ängern im Prinzip bereits in den Anfängen des Internets. Bislang musste der Nutzer den
Weg zu den gewünschten Informationen noch selbst suchen. Mit der schnell zunehmenden
Anzahl an Seiten (und damit steigender Komplexität) im Internet wurde deutlich, dass
ein Bedarf an Strukturierung besteht, da der Nutzer sonst die gesuchten Inhalte nur noch
schwer nden kann.
Der erste Anbieter, der sich dieser Aufgabe widmete, war die Firma Yahoo!. Diese erstellte
einen Katalog, in dem die Seiten je nach Inhalt in Kategorien unterteilt werden konnte.
Dies ermöglichte dem Nutzer eine interessengesteuerte Suche. Solche Kataloge, auch Verzeichnisse
genannt, ndet man inzwischen bei fast jedem Anbieter von Suchmaschinen.
Später erweiterte Yahoo! sein Angebot um das Portal myYahoo!. Dieses ermöglichte dem
Nutzer eine persönliche Anpassung der Seite. Er konnte auswählen, welche Informationen
und Nachrichten er aus welchen Themengebieten präsentiert bekommen möchte. (vgl.
[WCR04])
6.1.2. Portale sind wie ein Einkaufszentrum...
Um den Sinn und Zweck von Portalen zu verstehen, kann man diese in gewisser Hinsicht
mit groÿen Einkaufszentren vergleichen. Beide haben eine groÿe Anzahl von Besuchern,
die viele verschiedene Ziele verfolgen. Manche suchen Informationen, andere müssen Aufgaben
erledigen, andere möchten etwas erwerben. Einkaufszentren bieten eine Fülle von
Geschäften auf kleinem Raum. Damit die Besucher dennoch eektiv (sowohl für den Besucher
als auch für das Einkaufszentrum) in dieser komplexen Struktur an ihr Ziel gelangen,
ist der Aufbau streng geplant. Die Besucher werden in gewisser Weise mit Hilfe von Hinweisen
und Wegplanung durch die Struktur gelenkt. Ähnlich ist es in einem Portal, es
gibt eine Fülle von Informationen und Diensten, die für einen Benutzer klar strukturiert
präsentiert werden, damit sich dieser leicht zurechtnden und diese eektiv nutzen kann.
In einem Einkaufszentrum gibt es aber nicht nur die Kunden. Es gibt auch die Mitar-
62

6.1. WAS SIND PORTALE UND WARUM NUTZT MAN SIE?
beiter. Diese nutzen das Einkaufszentrum auf eine ganz andere Art, sie verkaufen dort
zum Beispiel Waren und nutzen ganz andere Wege in dieser Struktur. Auch ein Portal
kann auf diese Art und Weise eine Seite für die Kunden und eine andere für Mitarbeiter,
beispielsweise des Unternehmens, welches das Portal betreibt, haben.
6.1.3. Was macht Portale aus?
Portale bieten dem Nutzer eine vordenierte, jedoch anpassbare Sicht auf Informationen.
Ebenso können sie mehr oder weniger spezialisierte Dienste anbieten, je nachdem, welche
Benutzergruppen ein Portal besuchen.
Ein weiteres wichtiges Merkmal ist die Trennung von Benutzergruppen. So ist es möglich,
in einem einzigen Portal verschiedene Inhalte für verschiedene Benutzergruppen anzubieten.
Für Unternehmen bedeutet dies zum Beispiel, dass sie eine zentrale Informationsplattform
sowohl für Angestellte als auch für Kunden betreiben können. Es gibt somit also
nur eine Anlaufstelle für beide Seiten und es kann ein zentrales Informationsmanagement
stattnden.
Als Beispiel könnte man ein Portal eines Internetversandhandels wählen. Das Portal bietet
einerseits dem Kunden die Möglichkeit, die Ware im Online-Shop einzusehen und Bestellungen
aufzugeben. Auf der anderen Seite haben die Mitarbeiter des Unternehmens die
Möglichkeit, die Bestellabwicklung direkt im Portal durchzuführen. Sie haben direkten
Zugri auf alle notwendigen Datenbestände und logistischen Informationen. Alle Daten
benden sich also in einem zentralen System. Somit müssen die Daten nicht mehr von
verschiedenen Systemen verarbeitet und zwischen diesen Systemen ausgetauscht werden.
Das ermöglicht beiden Benutzerseiten einen erleichterten Workow sowie weitere ökonomische
Vorteile, wie die Kostenreduktion durch Verwendung weniger Systeme und einer
einfacheren Wartung. (vgl. [WCR04], [LM04b])
6.1.4. Theoretisches Konzept
Wenn man Portale nun etwas spezieller in Hinsicht auf die verwendeten Internettechnologien
und das zugrundeliegende Konzept betrachtet, so lässt sich zusammenfassen, dass
Portale webbasierte Anwendungen sind, die eine nutzerorientierte Sicht auf Applikationen
und Content aus verschiedenen Bereichen in einer einheitlichen, einfachen und strukturierten
Oberäche zusammenfassen.
Die verwendeten Informationen können dabei aus den verschiedensten Quellen und Informationssystemen
wie Datenbankmanagementsystemen (DBMS), Content Management
Systemen (CMS), dem Dateisystem oder Rich Site Summary-Feeds (RSS-Feeds) stammen
und werden für den Portalnutzer je nach Bedarf aufbereitet. Typischerweise verfügen
Portale über ein integriertes User-Interface, welches eine individuelle Anpassung der
Contentpräsentation erlaubt.
Ein in vielen Portalen genutztes Feature ist das sogenannte Single Sign-On, oft einfach
SSO abgekürzt. Single Sign-On bedeutet, dass sich ein Portalnutzer nur einmal zu Beginn
(z.B. auf der Portalstartseite) am System mit seiner Benutzerkennung und seinem
63

KAPITEL 6. EINFÜHRUNG IN PORTALE UND PORTLETS
Passwort anmeldet und damit Zugri auf alle für Ihn bestimmten Inhalte und Dienste
innerhalb des Portales erhält, ohne sich bei diesen ein weiteres Mal anmelden zu müssen.
(vgl. [WCR04],[LM04b])
6.2. Technische und ökonomische Vorteile von
Portalen
Portale bieten den Unternehmen auch eine Reihe von technischen und ökonomischen Vorteilen,
die sie für einen Einsatz interessant machen. Einige Beispiele:
• Der Einsatz eines zentralen Systems sowohl für Kunden als auch für Mitarbeiter
ermöglicht eine einfachere Wartung. Wenn Mitarbeiter etwa Applikationen über das
Portal nutzen, so ist es nicht mehr notwendig, diese auf jedem Client in einem
Firmennetzwerk zu installieren.
• Den meisten Mitarbeitern wird die Bedienung eines Browsers und das Navigieren
auf Internetseiten bereits bekannt sein. Somit entstehen geringere Trainingskosten
für neue bzw. umgesteigende Mitarbeiter.
• Wenn die Mitarbeiter die Struktur und die Bedienbarkeit eines Portals erlernt haben,
so wird es ihnen mit groÿer Wahrscheinlichkeit leichter fallen, neue Applikationen
oder neue Contentbereiche im Portal zu nutzen, da die Grundstruktur und der Aufbau
eines Portales, ähnlich der Corporate Identity einer Firmenpräsenz im Internet,
immer ähnlich sein sollten.
• Das gesamte Managing der Applikationen kann über das zentrale System geschehen.
Die Verwaltung und Updates von Software müssen also nicht auf den einzelnen
verbundenden Clients stattnden, was nicht nur eine enorme Zeitersparnis, sondern
auch die Qualität der Software erhöht (es ist sichergestellt, dass die Software immer
auf dem aktuellen Stand ist und keine veraltete genutzt wird).
• Portale bieten zudem eine gröÿere Flexibilität gegenüber anderen Systemen. So sind
die verwendeten Technologien meist Betriebssystem-unabhängig und haben nur relativ
geringe Systemvoraussetzungen.
64

6.2. TECHNISCHE UND ÖKONOMISCHE VORTEILE VON PORTALEN
Abbildung 6.1.: Klassisches IT-System und dessen Abhängigkeiten (Abb. aus [WCR04])
Abbildung 1 zeigt ein klassisches IT-System eines Unternehmens und die Abhängigkeiten
der Clients von den Applikationen des Unternehmens. Jeder Client muss dabei eigentständig
für die Anmeldung an der Applikation sorgen und hat für verschiedene Arbeitsschritte
verschiedene Anlaufstellen. Man kann erahnen, dass dieses Prinzip mit wachsender Clientzahl
zu einer sehr komplexen und schwer zu verwaltenden Struktur anwachsen kann, die
auch eine erhebliche Netzwerkbelastung mit sich bringen kann. (Bei Nutzung von Applikationen,
die über ein Netzwerk miteinander oder etwa mit einem DBMS kommunizieren.)
Abbildung 6.2.: IT-Struktur unter Verwendung eines Portals (aus [WCR04])
Abbildung 2 zeigt eine IT-Struktur unter Verwendung eines Portals (bzw. eines Web Application
Servers, auf dem ein Portal läuft). Jeder Client hat somit nur noch diese eine
zentrale Anlaufstelle, an der er sich mittels Single Sign-On anmelden kann. Der Aufbau
65

KAPITEL 6. EINFÜHRUNG IN PORTALE UND PORTLETS
ist wesentlich einfacher und ermöglicht auch bei groÿer Clientzahl gute Verwaltungsmöglichkeiten.
Eine solche Struktur führt jedoch nicht zwangsläug auch zur Reduktion der Netzwerkbelastung.
Es ändert sich nicht Menge der Kommunikation zwischen Clients und Applikationen,
es ändert sich die Art, wie sich diese verteilt. So werden Teile des Netzwerkes
entlastet, während der zentrale Server gewissermaÿen der Flaschenhals im Netzwerk wird.
Man sollte also sicherstellen, dass dieser die notwendigen Ressourcen besitzt.
6.3. Möglichkeiten von und in Portalen
Im Folgenden werden nun einige Features vorgestellt, wie sie in vielen Portalen zu nden
sind. Es handelt sich dabei nur um eine Auswahl, die Grenze der Möglichkeiten beschränkt
sich lediglich auf die Grenzen der zugrundeliegenden Technologien.
• Ein Portal ermöglicht eine sehr exible Zustammenstellung von Content. Sie bieten
dem Benutzer einen konsistenten View auf gegebenenfalls aufbereiteten Content aus
den verschiedensten Informationssystemen.
• Ein Portal bietet angepasste Views auf den Content. Es ist nicht nur möglich, verschiedene
Views auf einen Content zu denieren, sondern man kann auch Content
mit verschiedenen Rechten versehen (ähnlich wie in Content Management Systemen).
Dies ermöglicht verschiedene Arten von Informationen innerhalb eines Views.
So könnte z.B. in einem News-Portal zwischen politisch interessierten und Sport
interessierten Endnutzern unterschieden werden, ohne dass jeweils ein eigener View
auf den zugrundeliegenden Content verwendet werden muss. In Unternehmenssicht
könnte jeder Mitarbeiter genu die Informationen erhalten, die er für seine Arbeit
benötigt.
• Das integrierte User-Interface ermöglicht eine personalisierbare Gestaltung der Seiten.
In vielen Portalen ermöglichen vorgegebene Templates dem Nutzer das lookand-feel
zu ändern. Weiterhin kann der Nutzer die Inhalte anpassen, das heiÿt, er
kann innerhalb seines Views und seiner Rechte wählen, wo und wie er welche Inhalte
präsentiert bekommen möchte.
• Portale bieten ein einheitliches Sicherheitsmodell. Das zuvor erwähnte Single Sign-
On bietet nicht nur Komfort für den Benutzer, sondern bringt auch mehr Sicherheit
mit sich. Die Verwaltung von Benutzerdaten muss nur an einer Stelle, etwa einer
Benutzerdatenbank stattnden, anstatt getrennt in jedem System oder jeder Applikation.
Somit können hierfür benötigte Ressourcen eektiver genutzt und in bessere
Sicherheitsmaÿnahmen investiert werden.
• Portale bieten Möglichkeiten zur gemeinsamen Arbeit, auch Kollaboration genannt.
Innerhalb des Portales ist es Mitarbeitern möglich, sich über ihre Arbeit auszutauschen
oder gemeinsam an Projekten zu arbeiten. Technische Grundlage hierfür
66

6.3. MÖGLICHKEITEN VON UND IN PORTALEN
bieten Chats, Diskussionsforen, Whiteboards oder die Möglichkeit, Kommentare zu
im Portal veröentlichten Artikeln zu verfassen.
• Die zentrale Struktur eines Portales und die Möglichkeit verschiedener Views und
Rechte ermöglichen eine einfache Lokalisation und Internationalisierung eines Portales.
So ist es vergleichsweise einfach, ein Portal an eine andere Sprache anzupassen,
wenn die funktionellen Texte (Button-Beschriftungen, Links, Überschriften, etc.) in
einer zentralen Sammlung verwaltet werden. Ebenso ist es möglich, lokalen Content
anzuzeigen. So könnte man Wetterdaten für den aktuellen Standort des Nutzers
anzeigen oder auch Informationen nach Abteilungen eines Unternehmens aufteilen.
• Die Integration von Applikationen und die Anbindung an mehrere verschiedene Informationssysteme
ermöglichen es, Workows in Portale einzubinden. So können
bestimmte Arbeitsabläufe bereits vorbereitet werden, indem alle für den Nutzer
notwendigen Informationen aus allen Quellen zusammengestellt und ihm optimal
präsentiert werden. Es ist auch denkbar, dass gewisse Schritte auch bereits automatisiert
ablaufen können, um so die Eektivität der Arbeit zu erhöhen. Ein Beispiel
für die Integration eines Workows lässt sich wieder an einer Bestellabwicklung verdeutlichen.
Ein Kunde gibt eine Bestellung im Portal auf. Der Mitarbeiter erhält
zusammen mit der Bestellung alle weiteren für den Ablauf wichtigen Informationen,
wie die Anschrift des Kunden, Zahlungsinformationen, aktuellen Lagerbestand der
bestellten Artikel, Versandzeiten, -informationen und -status des Logistikpartners
und ähnliches. Somit kann der Mitarbeiter schnellstmöglich alle wichtigen Arbeitsschritte
erledigen.
• Das einheitliche Sicherheitsmodell eines Portals stellt auch eine gute Grundlage für
die Intergration von anderen Webservices dar. So können Schnittstellen zu anderen
externen Informationssystemen integriert werden, um dem Nutzer eine noch gröÿere
Vielfalt an Informationsquellen zur Verfügung stellen zu können oder ihm zu
ermöglichen, Informationen direkt an andere Systeme zu übermitteln.
• Teilweise integrieren Portale auch erweiterte Funktionen, wie beispielsweise gemeinsame
Terminverwaltung, Projektplanung, Online-E-Mail-Clienten oder Versionsmanagement,
wie sie bereits aus anderer Groupware bekannt sind.
• Ein zentrales Portal kann mit den entsprechenden Sicherheitsvorkehrungen auch
von auÿerhalb des Unternehmens genutzt werden. So kann etwa ein Mitarbeiter
Standort unabhängig auf alle wichtigen Daten zugreifen, um so auch auÿerhalb
möglichst eektiv arbeiten zu können.
• Obwohl die Strukturierung eines Portales dem Nutzer bei der Inhaltsndung helfen
soll, wird oftmals auf die zusätzliche Hilfe einer internen Suchmaschine gesetzt.
Diese Suchmaschine hilft Nutzern, wenn sie nicht genau wissen, wonach oder wo
sie suchen sollen oder wenn ein schneller bereichsübergreifender Überblick über eine
Menge Informationen benötigt wird.
67

KAPITEL 6. EINFÜHRUNG IN PORTALE UND PORTLETS
• Ein häuger zu ndendes Feauture innerhalb von Portalen ist der Zugri auf eine
interne Datenbank über ein Webinterface. Somit können einfache Transaktionen und
Abfragen auf den Datenbankbeständen ausgeführt werden ohne dass der Nutzer eine
SQL-Abfragesprache beherrschen muss.
Abbildung 6.3.: Portal Integration zwischen Clients und Informationssysteme (aus
[WCR04])
Portale bieten nicht nur eine gute Anbindung an eine Vielzahl von Informationssystemen,
sondern sind auch exibel gegenüber den auftretenden Clients (siehe Abbildung 3).
Mit entsprechenden Schnittstellen, Templates und verwendeten Techniken (beispielsweise
WAP oder XHTML mobile) ist etwa auch die Anbindung von mobilen Geräten wie
Handys, PDAs und anderen möglich. (vgl. [WCR04],[LM04b])
68

6.4. WAS IST BEI DER ENTWICKLUNG VON PORTALEN ZU BEACHTEN?
6.4. Was ist bei der Entwicklung von Portalen zu
beachten?
Der eektive Einsatz eines Portales hängt davon ab, wie gut die Entwickler das Portal
den Bedürfnissen der künftigen Nutzer angepasst haben. Dieser Nutzer-orientierte Ansatz
stellt den Kern eines Portales dar und muss somit konsequent beachtet werden. Es ist sehr
wichtig, die Nutzergruppen gut zu analysieren, um Views entsprechend Ihren Bedürfnissen
zu generieren. Nur wenn die Benutzer sich im Portal zurechtnden und ihre Vorhaben
schnell und möglichst einfach ausführen können, wird es von ihnen angenommen werden.
Man sollte auch bei der optischen Gestaltung des User-Interfaces an die Nutzer denken.
Es geht nicht darum, die Funktionsvielfalt so eindrucksvoll wie möglich zu präsentieren,
sondern darum, dem Nutzer den Aufbau so leicht wie möglich zu verdeutlichen und ihm
eine, im Rahmen des möglichen, intuitive Navigation zu ermöglichen. Gerade mit Inhalten
und Auswahlmöglichkeiten überladene Portalstartseiten wirken eher abschreckend für
einen Nutzer.
Auch wenn das look and feel eines Portales durch den Nutzer zum Beispiel durch Templates
angepasst werden kann, so ist es wichtig, das Default-Template unter Beachtung der
erwähnten Aspekte möglichst eektiv zu gestalten, denn eine groÿe Anzahl der Nutzer
wird dieses voreingestellte Template beibehalten und keine eigenen Änderungen an der
Gestaltung vornehmen.
Weiter sind andere Aspekte zu beachten. So ist es wichtig, die Art des Contents für ein
Portal zu bestimmen. Nicht jeder Content ist bereit für die Präsentation in einem Portal
und muss eventuell aufgearbeitet, zum Beispiel formatiert, werden. Zudem muss ermittelt
werden, wer welchen Zugri auf den Content erhalten soll. Diese Aufarbeitung von Content
kann viel Arbeit bereiten und sollte bei der Entwicklung eines Portals entsprechend
bedacht werden. Auch die Content-Pege kann sehr zeitaufwendig sein. Um diese zu erleichtern,
sollte man Metadaten (wie zum Beispiel das Dublin Core Metadata Element
Set) nutzen. Jedoch sind diese nicht immer verfügbar, müssten also noch erzeugt werden.
Dies kann wiederum sehr hohen Aufwand bedeuten und kann sehr viel Zeit in Anspruch
nehmen. Es ist also wichtig, dass man gut plant welche und wie viele Inhalte man in einem
Portal zur Verfügung stellen will. Wenn man keine gute Struktur in den Inhalten besitzt,
um diese eektiv durchsuchen und verwalten zu können, so wird auch ein gut konzipiertes
Portal keinen Erfolg haben. (vgl. [LM04b])
6.5. Was sind Portlets?
Portlets sind die individuellen Komponenten, aus denen ein Portal besteht. Es handelt
sich bei Portlets im Prinzip um gekapseltes Applikationen, die dem User einen im Portlet
denierten View auf die Daten eines DBMS oder CMS liefern und per Knopfdruck
ins Portal eingefügt und wieder entfernt werden können. Ein Portlet kann zum Beispiel
Informationen aus einem CMS lesen, diese formatieren und dem Nutzer die Informationen
auf der Portalseite präsentieren. Eine andere Möglichkeit wäre ein Portlet, dass dem
69

KAPITEL 6. EINFÜHRUNG IN PORTALE UND PORTLETS
Benutzer erlaubt, auf eine Datenbank zuzugreifen. Es stellt ihm die notwendige Eingabemaske
zur Verfügung, mit der der Nutzer zum Beispiel eine Bestellung suchen kann.
Wenn der Nutzer eine Anfrage sendet, so ndet die Abarbeitung durch das Portlet auf
Serverseite statt. Die Datenbank würde in diesem Fall das Ergebnis an das Portlet liefern,
welches dieses dann dem denierten View entsprechend aufbereitet und dem Nutzer dann
als Inhalt präsentiert.
Portlet-Applikationen sind also eigentlich erweiterte Web-Applikationen und sind auch
ähnlich aufgebaut. Sie bestehen in der Regel aus einer konventionellen Web-Applikation,
also Servlets, JSPs, statischem Content, Bildern oder ähnlichem, haben einen Web Deployment
Descriptor (web.xml), einen Portal Deployment Descriptor (portlet.xml) und
enthalten die Portlets.
Die Portlet-Applikationen werden serverseitig im Portlet Container, einer Erweiterung
des Serverlet Containers ausgeführt. Der Portlet Container ist dabei nicht eigenständig,
sondern setzt auf einem anderen Container, zum Beispiel dem Jakarta Tomcat Container,
auf.
Clients kommunizieren mit dem Portlet über das Request-/Response-Verfahren. Wenn
ein Client also eine Anfrage erhält, so bearbeitet es die Anfrage gemäÿ seiner Programmierung
und generiert dynamischen Content in Form von sogenannten Fragmenten. Diese
Fragmente werden an den Portlet Container übergeben, welcher diese dann in Portal Pages
aggregiert und an den Client als statischen Content übergibt. Um eine Möglichst hohe
Wiederverwendbarkeit der Portlets zu ermöglichen, haben sich die führenden Portalvertreiber
zusammen gesetzt und einen gemeinsamen Standard für Portlets entwickelt. Das
Ergebnis ist die Java Portlet API oder JSR 168. Portlets, die unter Beachtung dieses
Standards entwickelt werden, können ohne gröÿeren Aufwand in jedes Portal integriert
werden, welches diesen Standard unterstützt. (vgl. [WCR04],[LM04b],[Ker04b])
6.6. Fazit
Portale im Internet können einer Vielzahl von Zwecken dienen. Allen ist aber gemeinsam,
dass der Nutzer sein angestrebtes Ziel möglichst einfach und eektiv erreichen soll. Das
Internet hat eine Gröÿe erreicht, dessen Struktur und Komplexität ohne Hilfe für kaum
jemanden durchschaubar sind. Portale bieten hier eine gute Anlaufstelle für Nutzer, um
schnell und eektiv an bestimmte Informationen zu gelangen.
In Unternehmen eingesetzt können Portale die Produktivität der Mitarbeiter steigern,
Arbeitsabläufe beschleunigen und vereinfachen, die IT-Infrastruktur eines Unternehmens
in einem System vereinen und weitere ökonomische Vorteile mit sich bringen.
Schon jetzt nutzen viele Unternehmen, Behörden und andere Einrichtungen, ob Groÿkonzern
oder kleinerer Betrieb Portale um so Ihre Internetpräsenz auszubauen. Es ist
wahrscheinlich, dass dieser Portalboom auch in Zukunft weiter zunehmen wird und die
Entwicklung und die Einsatzmöglichkeiten von Portalen sich weiter ausdehnen wird.
70

7. Java Portlet API JSR168
Diese Ausarbeitung gibt eine Einführung in die Java Portlet Spezikation (JSR 168) und
den WSRP (Web Services für Remote Portlets) Standard. Der Java Specication Request
168 Portlet Specication (JSR 168) [AH03] standardisiert die Entwicklung von Komponenten
für Portal Server. Der Standard wurde mit der Unterstützung namhafter Unternehmen
entworfen und im Oktober 2003 mit der Versionsnummer 1.0 verabschiedet. Beteiligt waren
z.B. die Apache Software Foundation, Boeing, DaimlerChrysler, Hewlett-Packard und
Novell. Mit dem JSR 168 wird ein allgemeines Portlet API deniert, das Möglichkeiten
zur Personalisierung, Präsentation und Sicherheit zur Verfügung stellt. Portlets, die mit
diesem API erstellt wurden, können in jedem standardkonformen Portal deployt werden.
Im JSR 168 werden folgende Themen behandelt[Mic03]:
1. Der Portlet-Container Contract und Portlet-Lifecycle Management
2. Die Denition von Fensterzuständen und Portletmodi
3. Die Verwaltung von Portlet-Preferences
4. Benutzerinformationen
5. Packaging und Deployment
6. Sicherheit
7. JSP Tags zur Unterstützung bei der Portlet Entwicklung
WSRP (Web Service for Remote Portlets) wurde von OASIS (Organisation for the Advancement
of Structured Information Standards) entwickelt. WSRP ist ein Web-Services-
Standard, der die Integration von Remote Content und Applikationen in Portale erlaubt.
7.1. Portlet API
Ein Client interagiert mit einem Portal über das Request/Response-Paradigma. Das Portal
übermittelt die im Request enthaltene Information via Portlet Invoker API an den
Portlet-Container, der wiederum mit der spezischen Portlet-Applikation via Portlet API
kommuniziert. Die Portlet-Applikation generiert (dynamischen) Content in Form von so
genannten Fragmenten, der vom Portal entsprechend aggregiert und an den Client als
Response übergeben wird [Ker04a, S.34]. Einen Überblick der Portal-Architektur gibt
Abbildung 1.
71

KAPITEL 7. JAVA PORTLET API JSR168
Abbildung 7.1.: Überblick der Portal-Architektur [Ker04a, S.34]
Alle Portlets müssen die Interfaces Portlet und PortletConfig implementieren. Das
Portlet API enthält die abstrakte Klasse GenericPortlet, welche diese Interfaces schon
implementiert und mit Basisfunktionalitäten ausgestattet ist. Bei der Entwicklung von
Portlets erweitert man normalerweise GenericPortlet und überschreibt ggf. Methoden.
7.1.1. Container Contract und Lifecycle
Die Ablaufumgebung von Portlets ist der Portlet-Container. Im sogenannten Container
Contract ist festgelegt, dass der Portlet-Container bestimmte Methoden zu fest denierten
Zeitpunkten im Lebenszyklus eines Portlets aufrufen muss. Im Portlet Interface sind
vier Lifecycle-Methoden festgelegt, die der Entwickler mit Funktionalität ausstatten kann
[Ker04a, S.37-38]:
1. init(PortletConfig config): Diese Methode wird einmalig nach Instantiierung
des Portlets aufgerufen und dient zur Initialisierung sowie zur Bereitstellung von
Ressourcen.
2. processAction(ActionRequest request, ActionResponse response) : Diese Methode
wird bei Ausführung eines sog. Action-Request, der vom zugrunde liegenden
Portlet via createActionURL()-Methode im javax.portlet.RenderResponse Objekt
initiiert wird, aufgerufen und dient zur Bewältigung der folgenden Aufgaben:
• Änderung des Portlet-Mode
• Änderung des Window-State
• Redirect
• Modizierung der User-Preferences
72

7.1. PORTLET API
• Setzen von Render-Parametern, auf die dann in der render(...)-Methode zugegrien
werden kann
3. render(RenderRequest request, RenderResponse response): Diese Methode wird
entweder innerhalb eines Action Request nach der processAction(...) -Methode,
oder aber innerhalb eines Render-Request direkt aufgerufen. In der Methode ndet
die Content-Generierung statt. Dies kann entweder über die Methoden
getPortletOutputStream() und getWriter() des Objektes RenderResponse geschehen
oder aber via JSP/Servlet-Delegierung.
4. destroy(): Diese Methode wird einmalig vor dem Beenden des Portlet aufgerufen
und dient üblicherweise der Entfernung von Ressourcen.
7.1.2. Window-State und Portlet-Mode
Im Portlet-Fenster kann man mit Buttons den Window-State des Portlets verändern. Der
Window-State zeigt dem Portlet an, wieviel Platz auf der Portal-Seite reserviert ist. Das
ermöglicht es dem Portlet sein rendering an den Fensterzustand anzupassen. Die folgende
Tabelle zeigt die im Portlet API denierten Fensterzustände [Ric04, S.16].
Window State
NORMAL
MINIMIZED
MAXIMIZED
Beschreibung
Das Portlet muss sich den Platz mit anderen Portlets
teilen
Das Portlet enthält keinen oder minimalen Output
Das Portlet teilt sich den Platz nicht mit anderen Portlets
und ist daher in seinem Output nicht beschränkt
Tabelle 7.1.: Im Portlet-API denierte Fensterzustände
Der Fensterzustand kann mit der Methode getWindowState() des PortletRequest Interfaces
abgefragt werden.
Ausserdem kann man über Buttons im Header des Portlets den Portlet-Mode ändern. Der
Portlet-Mode informiert das Portlet, welcher Task zu erledigen und welcher Content zu
generieren ist. Die Spezikation deniert die folgenden Portlet-Modes:
• VIEW: Default Mode, in dem das Portlet standardmässig gestartet wird. Zeigt den
aktuellen Content des Portlets an und ermöglicht Interaktion.
• EDIT: In diesem Mode kann der Benutzer Eigenschaften des Portlets kongurieren.
Diese PortletPreferences liegen in Key/Value Notation vor und sind vom Portal
persistent zu halten.
• HELP: Hier können Hilfeinformationen für den Benutzer hinterlegt werden.
Für jeden Portlet-Mode gibt es eine entsprechende Methode in der Klasse GenericPortlet.
In den Methoden doView(), doEdit() und doHelp() wird der Content generiert, den
73

KAPITEL 7. JAVA PORTLET API JSR168
das Portlet in dem dazugehörigen Mode anzeigen soll. Wenn ein Portlet einen Render-
Request erhält, wird die Methode render() des Portlet Interfaces aufgerufen. In Klassen,
die von GenericPortlet abgeleitet sind, wird der Titel für das Portlet gesetzt und
die doDispatch() Methode aufgerufen. Die Methode doDispatch() überprüft durch den
Fensterzustand (normal, maximized oder minimized), ob etwas angezeigt werden soll.
Wenn der Fensterzustand nicht minimized ist, wird entsprechend des Portlet-Mode der
Methodenaufruf an doView(), doEdit() oder doHelp() weitergeleitet [LM04a, S.15]. Abbildung
2 zeigt eine Portal-Page auf Basis des Portals Liferay.
Abbildung 7.2.: Beispiel einer Portal-Page auf Basis des Portals Liferay [Ker04a, S.36]
7.1.3. Die Verwaltung von Portlet-Preferences
Portlets können Benutzereinstellungen in einem persistenten Speicher ablegen, der vom
Portal oder Portlet-Container verwaltet wird. Anstatt die Benutzereinstellungen in einer
Datenbank oder in Textdateien zu speichern werden die sog. Portlet-Preferences verwendet,
die aus Name-/ Wert-Paaren bestehen. Die Darstellung und das Verhalten eines
Portlets können so an verschiedene Benutzer angepasst werden.
Portlets haben bei der Verarbeitung eines Requests über das PortletPreferences Interface
Zugri auf ihre Preferences. Das Interface stellt getter- und setter-Methoden für
den Zugri auf und die Manipulation von Preferences zur Verfügung. Die Werte sollten
nur in der Methode processAction() verändert werden [AH03, S.57]. Es besteht die
Möglichkeit über den Deployment-Deskriptor Default Werte für die Portlet-Preferences
zu übergeben (Listing 1).
...
Listing 7.1: Deployment-Deskriptor mit Portlet-Preferences
74

7.1. PORTLET API
PreferredStockSymbols
FOO
XYZ
true
quotesFeedURL
http://www.foomarket.com/quotes
com.foo.PreferencesValidator
Zur Überprüfung der Portlet-Preferences kann eine eigene Klasse implementiert werden.
Dieser PreferencesValidator wird dann vor jedem Speichervorgang vom Portlet-
Container aufgerufen, um die vom Benutzer gemachten Einstellungen zu überprfen (z.B.
ob eine eingegebene Postleitzahl gültig ist).
7.1.4. Benutzerinformationen
Im JSR 168 ist auch ein Mechanismus enthalten, mit dem ein Portlet auf Benutzerdaten
des Portals zugreifen kann. Dazu sind eine Menge Attribute deniert (z.B. user.name.nickName)
auf die einfach zugegrien werden kann. Die vom Portlet benutzten Attribute müssen im
Deployment-Deskriptor angegeben werden (Listing 2). Für das Mapping zu den Daten
des Portal Servers ist der Deployer zuständig.
Listing 7.2: Deployment-Deskriptor mit User-Attributes
User Given Name
user.name.given
User Last Name
user.name.family
20
7.1.5. Packaging und Deployment
Eine Portlet-Anwendung besteht aus den Portlet-Classles, einem Web Deployment-Deskriptor
(web.xml) und einem Portlet Deployment-Deskriptor (portlet.xml). Darüber hinaus
75

KAPITEL 7. JAVA PORTLET API JSR168
können noch zusätzliche Bibliotheken (z.B. jar-Files) und Ressourcen (z.B. JSPs) verwendet
werden. Die vorgegebene Verzeichnisstruktur zeigt Abbildung 3. Die Portlet-
Anwendung wird in ein WAR-Archiv verpackt und im Portal deployt.
Abbildung 7.3.: Verzeichnisstruktur WAR-Archiv [Eigene Darstellung]
Der portlet.xml Deployment-Deskriptor
In der Datei portlet.xml sind die Meta-Informationen deniert, die der Portlet-Container
benötigt, um das Portlet zu starten. Der Portlet-Container legt für jede in portlet.xml
angegebene Portlet-Klasse genau ein Objekt an, das Requests an dieses Portlet bearbeitet.
Listing 7.3: Deployment-Deskriptor portlet.xml
Stephans 2nd Portlet
AdvancedPortletSK
Advanced Portlet SK
AdvancedPortletSK
text/html
VIEW
EDIT
HELP
Advanced Portlet SK
Adv Portlet SK
Advanced, Portlet
76

7.1. PORTLET API
Der Ausschnitt in Listing 3 zeigt die wichtigsten Elemente eines Portlet Deployment-
Deskriptors. In wird ein Name für das Portlet festgelegt und in
werden die Classles angegeben. In wird deniert, welchen Content
das Portlet untersttzt und welche Modes bei genau dieser Art von Content angezeigt
werden sollen. In stehen dann noch Zusatzinformationen, wie z.B. ein Default-
Titel [Mic03, S.13].
Der web.xml Deployment-Deskriptor
Da es sich bei Portlets um erweiterte Web-Anwendungen handelt, muss auch ein web.xml
Datei angegeben werden. Der Deployment-Deskriptor für Web-Anwendungen ist detailliert
in der Servlet Spezikation 2.3 beschrieben. Für ein einfaches Portlet genügt die
Angabe des Namens der Web-Anwendung.
Listing 7.4: Deployment-Deskriptor web.xml
Advanced Portlet SK
7.1.6. Sicherheit
Die Portlet Spezikation enthält einige Features, die dem Entwickler beim Entwerfen von
sicheren Portlets helfen sollen. Enthält ein Portlet z.B. vertrauliche Informationen kann
die Datenbertragung mit HTTPS verschlsselt werden. Ausserdem kann das Portlet auf
Benutzer- und Rolleninformationen zugreifen. Der Portlet-Container muss dem Portlet
mitteilen zu welcher Rolle ein Benutzer gehört, der auf das Portlet zugreifen will. Dadurch
kann der Zugri auf bestimmte Daten nur Benutzern erlaubt werden, die zu einer
festgelegten Rolle gehören. Wie Benutzer oder Rollen genau deniert sind wird dabei
nicht durch die Spezikation festgelegt. Das kann z.B. durch einfache Textdateien oder
über einen Directory-Server erfolgen. Der Portlet-Container kümmert sich nicht um die
Authentizierung der Benutzer. Das ist Aufgabe des Portals.
7.1.7. JSP Tags zur Untersttzung bei der Portlet Entwicklung
Mit der Portlet Tag Library können in einem Portlet enthaltene JSPs direkt auf Portlet
spezische Elemente wie RenderRequest und RenderResponse zugreifen. Ausserdem
können JSPs damit Funktionalitäten eines Portlets, wie z.B. die Erstellung einer Portlet
URL, erlangen. Jeder Portlet Container muss eine Implementierung der Portlet Tag
Library enthalten [AH03, S. 97].
77

KAPITEL 7. JAVA PORTLET API JSR168
7.2. Web Service for Remote Portlets (WSRP)
Im WSRP Standard ist festgelegt wie ein lokales Portal (Konsument) mit einem Portal
auf einem entfernten Server (Produzent) kommunizieren muss, um ein Portlet anzeigen
zu können, das auf dem entfernten Portalserver installiert ist. Der Standard wurde zwar
zusammen mit dem JSR 168 entwickelt, ist aber Programmiersprachen unabhängig. Mit
dem Standard wird ein hohes Mass an Interoperabilität erreicht, weil dadurch mit .NET
geschriebene Portlets auf einem Java-Portal angezeigt werden können und umgekehrt. Die
WSRP Spezikation wurde von OASIS (Organisation for the Advancement of Structured
Information Standards) entworfen und bendet sich zur Zeit in der Version 1.0.
Bei WSRP handelt es sich um sogenannte Visual, User-facing Web Services. Auf eine
Portal-Architektur bezogen bedeutet dies, dass es nicht notwendig ist, für einen spezi-
schen Web-Service ein spezisches Portlet zu entwickeln, um den Web-Service in das
Portal integrieren zu können. Stattdessen können solche Web-Services, die auf völlig verschiedenen
Architekturen (z.B. J2EE oder .NET) basieren können, via generischem Portlet
Proxy dynamisch dem zugrunde liegenden Portal hinzugefügt werden. Ein solcher Portlet
Proxy kommuniziert über fest denierte Interfaces mit dem (Remote) Portlet, welches
den Web-Service wiederum kapselt. Ein solches Portlet muss demnach nicht zwingend
auf demselben Rechner wie das Portal installiert sein. Solche (Remote) Portlets sind als
Web-Service auf einem (Remote) Server installiert und via UDDI Directory veröentlicht.
Dadurch können diese Portlets (häug spricht man von WSRP Services) einfach gefunden,
gebunden und letztlich in das Portal integriert werden [Ker04a, S. 36]. Abbildung 4 zeigt
einen Überblick der Portal-Architektur bei der Verwendung von WSRP.
Abbildung 7.4.: Portal-Architektur bei Verwendung von WSRP [Ker04a, S. 36]
78

7.2. WEB SERVICE FOR REMOTE PORTLETS (WSRP)
Ein nach dem WSRP Standard entwickeltes Portlet kann unabhängig von Content, Benutzer
Informations- oder Preferences-Modell auf jedem WSRP konformen Konsumenten
angezeigt werden. WSRP Portlets sind darstellungs- und nicht datenorientiert wie andere
Web Services. Deshalb muss kein datenorientierter Web- Service benutzt werden, um anschliessend
mit dem Ergebnis Content zu generieren. Die WSRP Architektur ermöglicht
das komplette Portlet über einen Web-Service darzustellen, ohne irgendwelche Anwendungslogik
auf dem konsumierenden Portal zu haben. Abbildung 5 zeigt eine typische
WSRP-Architektur mit zwei Produzenten und einem Konsumenten.
Abbildung 7.5.: Typische WSRP-Architektur [Eigene Darstellung]
79

8. Die Portal-Plattform Liferay
Diese Ausarbeitung beschreibt die Portal-Plattform Liferay.
Sie soll im Einzelnen auf die Funktionalitäten und Features des Softwareproduktes Liferay
als Portalplattform zur Entwicklung eines Portalsystems eingehen, sowie technische
Hintergrundinformationen zur Architektur dieses Systems vermitteln.
8.1. Was ist Liferay?
Liferay (oder das Liferay Enterprise Portal, kurz:LEP) startete im Jahre 2000 als Projekt
der Amerikaner Brian Chan, Bryan Cheung, Brian Kim und Michael Young mit dem
Ziel non-prot Organisationen einen Open-Source Lösung für ihren Internetauftritt zu
bieten. Mittlerweile hat sich aus diesem Verbund die Firma Liferay LLC gebildet, die
das LEP als eines der führenden Enterprise-Lösungen im Bereich J2EE Portalsysteme
weiterentwickelt und vermarktet.
Das Liferay Enterprise Portal selbst steht dabei unter einer Open-Source Lizenz (MIT-
License), womit der Sourcecode des Systems einer weltweiten Community an Programmieren
und Interessierten zur Weiterentwicklung zur Verfügung steht allerdings bedeutet
das nicht das Liferay LLC seine eigenen Anpassungen und Optimierungen (beispielsweise
spezielle Anpassungen nach Kundenwünschen) auch wieder veröentlichen muss, die
MIT-Lizenz ist an dieser Stelle weniger restriktiv wie z.B. die GPL.
Liferay ist eine Portalplattform. Das bedeutet im speziellen das sich auf Basis dieses Systems
individuelle Portallösungen für z.B. Firmenauftritte im Internet oder Organisationen
anderer Art (wie in unserem speziellen Fall eine Universität) entwickeln und betreuen lassen.
Dem Benutzer werden über ein Portal vordenierte Inhalte präsentiert, wobei der
Benutzer (ggf.) in der Lage ist spezielle Inhalte auszublenden oder vordenierte Dienste
zu nutzen. Das Portalsystem ist dabei im Speziellen in der Lage Benutzer in Gruppen zu
klassizieren und angepasste Inhalte zu präsentieren.
Das LEP stellt nun eine Plattform dar auf deren Basis man ein Portal mit strukturierten
Inhalten erstellen kann. Liferay selbst liefert bereits über 50 solcher Inhalte in Form von
Portlets mit, wobei unter anderem ein Content-Management System, Blogs, Calender, ein
Shopping-System und vieles mehr bereits vorhanden ist. Das LEP unterstützt wichtige
Standards wie z.B. JSR-168 (Portlet-API) oder JSR-220 (Hibernate) wodurch die Integration
eigener Inhalte oder sogar fremder Dienste (nach WSRP-Standard) auf Basis
von Java möglich ist.
80

8.2. FEATURES
8.2. Features
In der Honung das das nachher nicht zu sehr nach einem Liferay-Werbeprospekt aussieht
sollen an dieser Stelle einige Features von Liferay vorstellt werden.
8.2.1. Themes
Liferay verfügt bereits standardmässig über eine groÿe Anzahl an Themes, mit denen der
Benutzer seine Ansicht auf das Portal personalisieren und anpassen kann. Desweiteren
kann der Benutzer über sogenannte Sub-Themes sein Theme noch weiter verändern, z.B.
die Schriftart anpassen oder neue Farben wählen (vgl Abb. 8.2).
Abbildung 8.1.: Liferay: Themes zur Personalisierung
Abbildung 8.2.: Liferay: Sub-Themes weitere Manipulationen der Ansicht
Sämtliche Themes basieren hierbei auf CSS und nutzen Standard DIV-Tags, so das es für
einen Entwickler sehr einfach ist neue Themes zu entwerfen oder gegebene Anzupassen.
8.2.2. Personalisierbarkeit
Ein wichtiges Merkmal für Portale ist, neben der Anpassung des Views durch z.B. Themes
die Personalisierbarkeit des Portals. Der Benutzer soll die Möglichkeit haben sich seine
Inhalte z.B. für seine Startseite in das Portal individuell zusammenzustellen natürlich
81

KAPITEL 8. DIE PORTAL-PLATTFORM LIFERAY
im Rahmen der Einschränkungen die ein Adminstrator dem Nutzer bzw. seiner Benutzergruppe
einräumt. Da die Inhalte einer Liferay-Portal-Seite alle als (JSR-168 ) Portlet
realisiert sind kann man diese (fast) beliebig positionieren und untereinander austauschen.
Neue Inhalte können ebenso einfach eingefügt werden.
Abbildung 8.3.: Liferay: Portletfunktionen dank AJAX jetzt auch per drag-n-drop
Durch Nutzung aktueller Web-Technologien wie AJAX lassen sich die Inhalte in der
aktuellen Version des Portalsystems sogar per drag-n-drop manipulieren.
8.2.3. CMS
Liferay verfügt über ein sehr exibles Content-Management System mit dem es dem
Portalbetreiber wechselnde Inhalte (z.B. News) auf seinen Seiten präsentieren kann. Dieses
System als Portlet unter dem Namen Liferay-Journal integriert verfügt ausserdem
über eine Dokumentenverwaltung (vgl. Abb. 8.4) sowie eine spezialisierte Image Gallery
zur Ablage von Bildern.
Abbildung 8.4.: Liferay: Dokumentennverwaltung als Portlet
82

8.2. FEATURES
Abbildung 8.5.: Liferay: Image Gallery
Da in den meisten Fällen die Content-Pege nicht in Händen eines Web-Entwicklers liegt,
sondern anderen Personen, die sich möglicherweise nicht direkt mit HTML-Code beschäftigen
wollen oder können steht hier ein simpler WYSIWYG-Editor zur Erstellung von
z.B. News oder Artikeln direkt im Portal zur Verfügung (Abb. 8.6). Im weiteren können
Artikel auch über XSL-Stylesheets formatiert und aus anderen Quellen importiert werden,
so das sich ein Kontakt des Autors zum Portalsystem ggf. komplett vermeiden lässt.
Abbildung 8.6.: Liferay: WYSIWYG Editor
8.2.4. Single-Sign-On
Das LEP bietet bereits eine fertige Schnittstelle zum SSO-System CAS der Yale University,
so das für die Integration von Liferay an ein evtl. bestehendes Softwaresystem keine
besonderen Hürden mehr bestehen. Ausserdem kann Liferay seine Benutzerdaten über
bestehende, fremde Datenbanken oder einen LDAP-Server beziehen, so dass in diesen
Fällen ein automatischer Abgleich der Benutzerdaten mit dem LEP möglich ist.
Eine Anbindung an Microsoft Exchange ist ebenso schon integriert - weitere Schnittstellen
können Entwickler über eine denierte API nachpegen.
83

KAPITEL 8. DIE PORTAL-PLATTFORM LIFERAY
ASP-Design
Liferay ist von Grund auf darauf ausgelegt in ASP-Umgebungen (ASP: Application
Service Provider) eingesetzt zu werden. Das bedeutet das es möglich ist verschiedene
Instanzen von Liferay auf einem (entsprechend leistungsfähigen) Applikationsserver sowie
Datenbankserver zu hosten, um so z.B. mehrere unterschiedliche Portale gleichzeitig zu
betreiben.
Application Server Agnostic
Liferay ist Application Server Agnostic (unabhängig vom Application-Server).
Das LRP unterstützt eine vielzahl unterschiedlicher Applikationsserver, es läuft z.B. auch
nur mit Servlet-Containern wie Tomcat und Jetty, als auch mit vollen J2EE-Kompatiblen
Servern wie Borland ES, JBoss+Jetty/Tomcat, JOnAS+Jetty/Tomcat, JRun,
OracleAS, Orion, Pramati, RexIP, Sun JSAS, WebLogic, und WebSphere.
Ein weiterer Vorteil der sich hier ergibt ist das das LEP (halt nicht nur durch Java) quasiunabhängig
vom Betriebssystem läuft. Die meisten dieser Application-Server sind bereits
auf unterschiedlich Systeme wie BSD, Linux , Solaris etc. portiert.
8.2.5. Einsatz von Spring
Da Liferays Business-Beans auf das Spring-Framework nutzen kann das LEP auch in nicht-
EJB Umgebungen eingesetzt werden. Spring entscheidet ob eine EJB-Implementierung
oder eine Standard POJO Implementierung der Business-Logik gewählt wird.
8.2.6. Hibernate
Durch den Einsatz von Hibernate als Datenbank-Abstraktions-Layer ist Liferay im Prinzip
vollkommen Datenbank-Unabhängig.
Hibernate sorgt automatisch für eine persistente Datenhaltung und stellt mit HQL
(Hibernate Querry Language) eine einheitliche Abfragesprache zur Datenbank zur Verfügung.
8.2.7. verschiedene Sprachmodule
Liferay unterstützt verschiedene Sprachen (vgl. Abb. 8.7) durch den Einsatz von JSTL
fmt-tags, so dass man Portlets vollkommen Sprach-unabhängig entwickeln kann, und auch
fremdsprachige Portlets mit geringem Aufwand lokalisiert.
84

8.3. TECHNOLOGIE
Abbildung 8.7.: Liferay: Lokalisiertung durch JSTL
8.2.8. Skalierbarkeit
Das LEP kann auf mehreren Servern verteilt installiert werden: wenn man so z.B. die Präsentationsschicht
(Servlet-Container) von EJB-Container und Datenbanksystem trennt.
LEP kann ausserdem, zur Verbesserung der Skalierbarkeit mit OSCache eingerichtet werden.
Man kann so zusätzlich vertikal skalieren (mehrere Application-Server mit clustered
cache).
8.2.9. Benutzergruppen und Rechtemanagement
Das Liferay-Portalsystem unterscheidet verschiedene Benutzergruppen. So ist es z.B. möglich
Portlets zu entwickeln die wissen zu welcher Benutzergruppe sie gehören - z.B. einen
Kalender der einen Termin nur Benutzern in der selben Gruppe bekanntgibt.
8.3. Technologie
Wie man bereits im vorhergehenden Kapitel erkennen konnte zeigt sich das das LEP eine
Vielzahl an unterschiedlichen J2EE Technologien zur Realisierung von echter Plattformunabhängigkeit
einsetzt.
Wie so oft zeigt sich hier eine typische Aufteilung in ein 3-Schichten Modell:
Anzeige: Struts und Tiles: Realisierung von Model 2 JSP (Servlet/JSP Trennung)
Logik: Spring und EJB: Kapselung der Business-Logik
Daten: Hibernate: Abstraktion der DB
Da die jeweilige Logik auf Basis dieser Abstraktions-Schichten selbst wieder in gewisser
weise unabhängig von der eingesetzten Software ist (z.B. bei Hibernate (fast) unabhängig
vor der Datenbank) ergibt sich für das LEP eine recht komplexe Deployment Matrix
(Abb. 8.8).
85

KAPITEL 8. DIE PORTAL-PLATTFORM LIFERAY
Abbildung 8.8.: Liferay: Demployment-Matrix
Folglich kann man Liferay auf insgesamt 700 verschiedene Arten installieren.
8.4. Systemarchitektur
Das LEP bietet mehr als nur nur den traditionellen Zugri auf das Portalsystem durch
z.B. den Browser oder von einen einem PDA die Business-Logik des Portalsystems kann
auch z.B. über eine spezialisierte API via SOAP oder RMI als Web-Dienst zugreifbar
gemacht werden.
Zur Veranschaulichung der folgenden Beispiele sei hier die Systemarchitektur von Liferay
aufgeführt (Abb. 8.9).
86

8.4. SYSTEMARCHITEKTUR
Abbildung 8.9.: Liferay: Systemarchitektur
8.4.1. Traditioneller Web-zugri
Im Normalfall werden die Inhalte und Dienste des Portalsystems über einen Browser oder,
dann schon etwas exotischer, über ein kabelloses Endgerät (z.B. per Mobiltelefon über
WAP) geönet. Dieser Zugri verläuft über das Standard Struts-MainServlet. Struts
sorgt hierbei für eine konsequente Trennung von (Servlet)-Logik und Anzeige: das Servlet
selbst schickt ggf. die Benutzereingaben weiter an die Logik (Business Tier), hält die
Verbindung zu den EJBs und sorgt dafür, dass dem Benutzer eine dem Client entsprechende
Anzeige präsentiert wird (also dass ein text-basierter Browser z.B. keine Graken
geschickt bekommt) (JSP Model 2 Architektur).
Für komplexere Layouts im Browser steht ausserdem Tiles als Template-Engine zur Ver-
87

KAPITEL 8. DIE PORTAL-PLATTFORM LIFERAY
fügung.
Das Servlet greift nun über Spring auf die Business-Logik des Dienstes zu, welche entweder
in Form einer Enterprise-Java Bean Implementierung oder als normales Plain Old
Java Object (POJO) vorliegt.
Zugrie in die Datenhaltung erfolgen dann über Hibernate oder aber z.B. über JMS
auch andere Dienste sind denkbar.
8.4.2. Liferay als Web-Service-Provider
Alternativ ist es denkbar, dass man auf die Dienste/Funktionalität des Portalsystems als
Web-Service verfügen möchte oder auch muss. Der Zugri auf den Business-Tier erfolgt
in diesem Fall über ein spezialisiertes Servlet (Axis-Servlet) mit eigener API, oder ein
getunnelter Zugri durch das zur Verfügung gestellte Tunnel Servlet (Zugri ohne GUI)
oder auch direkt via RMI/SOAP, was allerdings im Normalfall nur zu Testzwecken
realisiert wird.
Ein Spezialfall ist hier sicherlich das exportieren ganzer Portlets über WSRP.
8.5. Fazit
Liferay ist schon lange kein einfaches Portal mehr es ist zu einem sehr komplexen
Softwaresystem gewachsen. Durch den geschickten Einsatz von unterschiedlichen J2EE-
Technologien ist es gelungen, eine Portalplattform zu erstellen, die plattformunabhängig,
erweiterbar, sehr wandlungsfähig und zudem auch noch frei ist.
Da Liferay aber fast das gesamte Spektrum aktueller J2EE Java-Technologien in einem
Softwaresystem bündelt, holt man sich aber nicht nur deren Vorteile mit ins Haus, sondern
ebenso auch deren Probleme und Nachteile (z.B. betreend Performance). Zum zweiten
zeigt sich beim Entwickeln für diese Plattform sehr schnell, dass man dringend einen
J2EE-Spezialisten benötigt oder selbst zu einem werden muss.
88

9. Einführung in digitale
Bibliotheken
9.1. Einleitung
Für digitale Bibliotheken haben Computer und Netzwerke eine fundamentale Bedeutung,
sind aber nur die Technologie. Das Entscheidende an ihnen ist das Zusammenspiel von
Menschen, Organisationen und eben diesen Technologien [Arm00]. Dabei gibt es eine
klare Abgrenzung zwischen virtuellen und digitalen Bibliotheken. Während virtuelle Bibliotheken
1 eine sachlich geordnete Sammlung von Links und Volltexten haben, die nicht
ortsgebunden ist, beziehen digitale Bibliotheken neben den digitalen Dokumenten auch alle
Objekte aus einer existierenden Bibliothek mit ein. Eine vollständige digitale Bibliothek
hat demnach die Funktionen einer traditionellen Bibliothek, d.h. Sammeln, Auswählen,
Erschlieÿen und Aufbereiten für die Benutzung und Archivierung [Pay]. Dementsprechend
kann eine digitale Bibliothek wie folgt deniert werden:
A digital library is a managed collection of information, with associated services,
where the information is stored in digital formats and accessible over a
network. [Arm00]
Es ergeben sich hierbei folgende Fragen:
1. Welche Unterschiede und Vorteile haben digitale Bibliotheken im Vergleich zu den
traditionellen?
2. Welche Voraussetzungen, sowohl technisch als auch allgemein, müssen erfüllt werden?
3. Wie benutzen Bibliotheken und Verlage die neuen Technologien?
4. Wie entstehen neue individuelle Bibliotheken ohne den Einuss traditioneller Organisationen?
5. Welche Grundlagen und Konzepte gibt es zur Katalogisierung?
6. Welche weiteren Aspekte müssen berücksichtigt werden?
7. Welche Standards sind in den letzten Jahrzehnten entstanden?
Auf all diese Fragen versucht diese Seminarausarbeitung einzugehen, um einen Überblick
über dieses komplexe Thema zu geben. Es können dennoch nicht alle Details aufgezeigt
1
Beispiel: The WWW Virtual Library - http://vlib.org/
89

KAPITEL 9. EINFÜHRUNG IN DIGITALE BIBLIOTHEKEN
werden, da dies den Rahmen der Ausarbeitung sprengen würde. Vielmehr ist es empfehlenswert,
sich die fortführenden Texte Aufgaben und Formen digitaler Bibliotheken
(siehe Kapitel 10) und Verteilte und föderierte digitale Bibliotheken (siehe Kapitel 11)
anzuschauen.
9.2. Digitale Bibliotheken
Digitale Bibliotheken beinhalten diverse Ansammlungen von Informationen für viele unterschiedliche
Benutzer. Dabei spielt es keine Rolle, ob diese sehr klein und nur für spezielle
Themen verfügbar oder eine allumfassende, groÿräumige Bibliothek darstellen. Genauso
nebensächlich ist die verwendete Technologie, d. h. welche Computerperipherie oder Software
eingesetzt wird. Entscheidend ist nur, dass die Informationen auf Computern organisiert
und über Netzwerke verfügbar und die Standardfunktionen wie Sammeln, Auswählen,
Verfügbar machen und Archivieren vorhanden sind.
Trotz neu erfundener Technologien werden sich die Bedürfnisse der Benutzer kaum ändern,
vielmehr werden sie weiterhin Informationen erstellen und suchen. Deshalb müssen
Informationen auch künftig organisiert, gespeichert und veröentlicht werden. Die ständige
Entwicklung neuer Technologien führt daher zu einer Vielzahl unterschiedlicher Ansammlungen
digitaler Dokumente, die in Zukunft das Verhalten der Benutzer fundamental
verändern wird. Diese Veränderungen werden hauptsächlich durch zwei Nutzergruppen angetrieben
- zum einen die Verlage, Herausgeber und Bibliothekare, zum anderen durch Informatiker
und Informationswissenschaftler. Während diese Nutzergruppen anfangs eher
eigenständig entwickelt haben, entstehen inzwischen zahlreiche Kooperationen, die neue
Technologien verbessern und vereinfachen. Zusätzlich werden durch günstiges Equipment,
einfache Software und das Internet elektronische Informationen für jeden direkt verfügbar.
Auch Autoren brauchen nicht länger Verlage, um ihre Werke zu veröentlichen,sondern
können ihre Werke den Lesern direkt zugänglich machen.
Technologien beeinussen auch wirtschaftliche und soziale Aspekte von Informationen und
umgekehrt. Verlage und Bibliotheken haben eine lange Tradition physikalische Objekte
nicht nur Bücher, sondern auch Kartenmaterial, Photographien und andere Artefakte
zu verwalten und damit zu handeln. Wissenschaftler haben dagegen die Tradition, ihr
Wissen und ihre Informationen frei mit Kollegen zu teilen, ohne Bezahlung, auch wenn sich
früher nur wenige die damals sehr teuren Computer und Netzwerke leisten konnten. Aus
diesem Ansatz heraus entstand das uns heute bekannte WWW (WorldWideWeb) [WCd].
Einerseits unterscheiden sich digitale Bibliotheken von traditionellen Bibliotheken stark,
andererseits versuchen sie diese nachzubilden. So gibt es digitale Bibliotheken, in denen
der Benutzer erst bezahlen muss, bevor er die Sammlungen und Dienste nutzen darf. In
anderen Modellen tragen die Produzenten und Autoren die Kosten.
Der fundamentale Grund digitale Bibliotheken zu erschaen, liegt in der Honung, Informationen
besser als bisher verbreiten und zur Verfügung stellen zu können. Nichts desto
trotz werden nicht alle gedruckten Dokumente durch elektronische Medien ersetzt, auch
wenn dies technisch und wirtschaftlich machbar wäre. Das Druckerzeugnis spielt in unserer
Gesellschaft eine dominierende Rolle.
90

9.2. DIGITALE BIBLIOTHEKEN
In den folgenden Abschnitten werden einige Aspekte digitaler Bibliotheken aufgezeigt.
9.2.1. Vor- und Nachteile
Die neuen Technologien bieten den digitalen Bibliotheken erhebliche Vorteile. So bedingt
der Besuch einer traditionellen Bibliothek einen mehr oder weniger groÿen Aufwand, da
nicht überall gröÿere Bibliotheken vorhanden sind. An Universitäten ist dies meist nicht so
schwierig, jedoch haben die meisten Leute keine Universität oder Bibliothek in ihrer Nähe.
Auch für Ingenieure und Wissenschaftler ist es problematisch an neueste Informationen
zu gelangen. Digitale Bibliotheken bringen dagegen die Informationen zum Nutzer. Dieser
benötigt nur einen PC mit einen Netzwerk- / Internetanschluss um überall auf der Welt
Zugri auf die digitalen Medien zu haben.
Gedruckte Dokumente sind angenehm zu lesen, jedoch kann es sehr schwierig sein, gezielt
bestimmte Informationen zu nden. Meistens ist es ein glücklicher Zufall bestimmte
Dokumente in einer traditionellen Bibliothek zu nden. Mit Computersystemen lässt sich
wesentlich schneller und einfacher arbeiten. Auch wenn Suchmethoden noch nicht immer
so gut sind, wie es sich viele wünschen, so werden diese Systeme doch stetig verbessert
und erweitert.
Bibliotheken und Archive haben viele Einzelexemplare, die so nur an bestimmten Standorten
verfügbar sind. Digitale Bibliotheken könnten diese Informationen überall verfügbar
machen. Das Anfertigen von Kopien selten genutzter Materialien ist nicht nur kostspielig,
sondern auch aufwändig. Digitale Kopien lassen sich dagegen einfach erstellen, um so Duplikate
über die ganze Welt verteilt zur Verfügung zu stellen. So wären selbst Raritäten
problemlos nutzbar.
Viele wichtige Dokumente müssen regelmäÿig aktualisiert werden. Gedruckte Materialien
müssen aktualisiert und alte Kopien ersetzt werden. Die digitale Speicherung auf einem
zentralen Rechner kann Dokumente einfacher, schneller und billiger aktuell halten. Viele
Bibliotheken installieren immer dann, wenn neue Online-Versionen von Wörterbüchern
und Lexika erscheinen, diese auf den Bibliotheks-PCs.
Digitale Bibliotheken sind nicht nur überall, sondern auch rund um die Uhr erreichbar.
Die Studie einer britischen Universität hat gezeigt, dass über die Hälfte der Benutzer
auÿerhalb der Önungszeiten auf digitale Sammlungen zugreifen [Arm00]. Entscheidend
ist auch, dass Materialien in Online-Archiven niemals ausgeliehen, falsch einsortiert oder
gestohlen sein können. Dadurch sind Zugrie auf Dokumente einer Bibliothek von der
anderen Seite der Welt genauso einfach möglich wie Zugrie vor Ort. Dennoch besteht
auch die Möglichkeit, dass Computersysteme oder Netzwerke ausfallen. Trotzdem stehen
im Vergleich zu traditionellen Bibliotheken Informationen leichter überall und jederzeit
zur Verfügung.
Nicht für alle Informationen ist das Druckmedium die beste Speichermöglichkeit. Eine
Datenbank ist die beste Möglichkeit Umfrage-Daten zu speichern, um sie später per
Computer zu analysieren. Auch audio-visuelle Informationen lassen sich am Besten digital
speichern. So können komplett neue Formate entstehen, die nur für den digitalen
Gebrauch sinnvoll sind. Gerade in den letzten Jahren sind in diesem Bereich viele neue
91

KAPITEL 9. EINFÜHRUNG IN DIGITALE BIBLIOTHEKEN
Dienste entstanden, die zwar nicht im herkömmlichen Sinn als Bibliothek bezeichnet werden
können, doch auch gezielt Informationen organisiert speichern. Dazu gehören zum
Beispiel GoogleEarth 2 , Flickr 3 und YouTube 4 . Das Potenzial der Annäherung zwischen
diesen Diensten und Bibliotheken ist erstaunlich. So werden in den nächsten Jahren noch
viele weitere interessante Dienste und Verknüpfungen mit Bibliotheken entstehen.
Bei all diesen Vorteilen muss aber auch die Wirtschaftlichkeit einer digitalen Bibliothek
betrachtet werden, so dass im nächsten Abschnitt auf die Kosten eingegangen wird.
9.2.2. Kosten
Konventionelle Bibliotheken sind teuer, da sie Gebäude und teilweise mehrere hundert
Mitarbeiter bezahlen müssen. Hinzu kommen noch die Kosten für die Anschaung neuer
Dokumente und Materialien, für die nie genug Geld zur Verfügung steht. Aber auch das
Publizieren ist kostspielig, so dass einige Verlage für die digitale Version mehr verlangen,
als für das gleiche gedruckte Erzeugnis um Ihre Kosten zu kompensieren. So sind heutzutage
digitale Bibliotheken auch sehr teuer, teilweise sogar teurer, da viele Technologien noch
entwickelt werden müssen. Langfristig bieten digitale Bibliotheken ein enormes Einsparpotenzial,
da einerseits die Entwicklungskosten zurückgehen werden und andererseits viele
Fixkosten eingespart werden können. So werden anfangs die Anschaungskosten neuer
digitaler Dokumente noch hoch sein, doch werden kaum weitere Nutzungskosten entstehen.
Dies führt zu einer Umschichtung der Fixkosten sowie zu einem besseren Kosten /
Nutzen Verhältnis. Verlage, Herausgeber, Autoren und Bibliotheken werden unter diesem
Druck die wirtschaftlichen Denkweisen verändern müssen, da alte Preisstrukturen, die
unter anderem durch Druckkosten entstanden, für elektronische Veröentlichungen nicht
gelten.
Neben den Kosten spielen noch weitere technische und allgemeine Voraussetzungen eine
Rolle, um eine digitale Bibliothek erfolgreich aufzubauen.
9.2.3. Voraussetzungen
Als in den den späten Sechzigern die ersten seriösen Versuche zur Speicherung von Bibliotheksinformationen
auf Computern durchgeführt wurden, gab es eine Menge technischer
Barrieren Speicherplatz war teuer, Netzwerke so gut wie nicht vorhanden oder sehr
langsam und das Lesen an Bildschirmen war aufgrund niedriger Auösungen und schlechtem
Kontrast unangenehm. Erst seit den Neunziger Jahren wurden eine Reihe technischer
Errungenschaften entwickelt, die die letzten fundamentalen Barrieren zum Aufbau einer
digitalen Bibliothek auösten. Einige dieser Entwicklungen sind noch rudimentär und be-
nden sich im Aufbau, jedoch haben die immer günstiger werdenden Computer und das
Internet zu einen schnellen Anstieg von Informationsdiensten geführt.
Elektronischer Speicher wird billiger als Papier
2
3D Satellitenbilder - http://earth.google.com/
3
Groÿes freies Photoarchiv - http://www.flickr.com/
4
Entstehendes freies Videoarchiv - http://www.youtube.com/
92

9.2. DIGITALE BIBLIOTHEKEN
Groÿe Bibliotheken sind selbst für reiche Organisationen sehr teuer. Für die meisten Bibliotheken
betragen alleine die Kosten für die Gebäude über 25% des Gesamtbudgets.
Steht diesen zusätzliches Geld für neue Gebäude zur Verfügung, so muss dennoch genügend
Freiraum zur Expansion zur Verfügung stehen. Während die Kosten für neue
Gebäude zur Lagerung von weiteren Büchern voraussichtlich steigen werden, sinken die
Kosten für die elektronische Speicherung jährlich um ca. 30% [Arm00]. So werden in
Zukunft auch groÿe Objekte wie Videos, Bildersammlungen und Audioaufnahmen zunehmens
digital gespeichert werden.
Computer-Bildschirme werden angenehmer zu benutzen
Die Qualität der Darstellung von Dokumenten am Bildschirm war anfangs sehr schlecht,
so dass üblicherweise die Texte zum Lesen auf Papier ausgedruckt wurden. Seitdem die
Auösungen immer gröÿer werden, Schriften speziell für Monitore entwickelt werden und
die Qualität steigt, lesen immer mehr Menschen direkt vom Bildschirm, gerade dann, wenn
bestimmte Dokumente speziell für die Betrachtung am Bildschirm entworfen worden sind
wie zum Beispiel Webseiten. Dieser Trend wird durch immer bessere, billigere und
achere Bildschirme weiter steigen, auch wenn auf lange Sicht Computer das Buch zum
Lesen nicht ablösen werden.
Schnelle Netzwerke verbreiten sich immer weiter
Seit dem Internet-Boom in den Neunziger Jahren wächst das Internet kontinuierlich. Während
anfangs nur groÿe Konzerne und Universitäten über groÿe Netze verfügten und normale
Menschen sich per Modem ins Internet einwählten, so ist in den letzten Jahren die
Anzahl an Hochgeschwindigkeits-Anschlüssen rasend gestiegen. Weltweit stieg die Zahl
der ADSL-Anschlüsse von 58 Mio. im Jahr 2003 auf 115 Mio. im Herbst 2005 [WCa].
So ist es heutzutage in den meisten Ländern leichter Informationen über das Internet zu
erhalten, als ein gedrucktes Buch oder Zeitschrift zu erlangen.
Computer sind mobil geworden
Die Verfügbarkeit des Internets an immer weiteren Standorten, sei es durch Funknetze,
Internet-Cafes oder andere Internetanschlüsse, spielt auch für digitale Bibliotheken eine
wichtige Rolle. Dank immer schnelleren und besseren Laptops lassen sich Informationen
überall sammeln und verarbeiten. So kann man, selbst wenn man nicht mit dem Internet
und einer Online-Bibliothek verbunden ist, mit lokal gespeicherten Kopien weiterarbeiten.
Erreichbarkeit ist für digitale Bibliotheken von zentraler Bedeutung. Traditionelle Bibliotheken
sind oft Teil einer Organisation, die teure physikalische Sammlungen nur ihren
Mitgliedern zur Verfügung stellen und auch vielen Wissenschaftlern und Ingenieuren steht
oft nur eine kleine bis gar keine Bibliothekseinrichtung zur Verfügung. Dies erweckte schon
früh das Interesse des Institute of Electrical and Electronics Engineers (IEEE) 5 am elektronischen
Publizieren.
Ein weiterer Faktor bei der Planung einer digitalen Bibliothek spielt die eingesetzte Technologie.
So müssen clientseitig neben modernsten Computern und Programmen auch ältere
Systeme unterstützt werden, um eine höchstmögliche Benutzbarkeit zu gewährleisten.
5 http://www.ieee.org
93

KAPITEL 9. EINFÜHRUNG IN DIGITALE BIBLIOTHEKEN
9.2.4. Grundlegende Konzepte
Inhalte und Metadaten
Digitale Bibliotheken können jede Information speichern, die sich digital abbilden lässt.
Neben den digitalen Versionen von konventionellen Medien, wie z.B. Texte, Bilder und
Musik, lassen sich auch digitale Materialien speichern, die kein physikalisches Pendand
haben, wie Daten von wissenschaftlichen Instrumenten, Computerprogramme und Datenbanken.
Entscheidend bei der Speicherung ist die Unterscheidung zwischen Daten und Metadaten.
Als Metadaten bezeichnet man allgemein Daten, die Informationen über andere Daten
enthalten. Diese sind in 3 Kategorien einzuteilen:
• Beschreibende Metadaten, wie z.B. Literaturangaben
• Strukturelle Metadaten über Formate und Strukturen und
• Administrative Metadaten über Zugrisrechte und Genehmigungen
Somit besteht in der Regel in einer digitalen Bibliothek ein digitales Objekt aus Daten,
Metadaten und einem eindeutigen Identikator, welcher wiederum selbst ein Metadatum
ist. Um den Umgang mit diesen Dokumenten zu vereinfachen, ist es nützlich Strukturen
und Klassizierungen zu denieren. Jedoch ist bei so vielen unterschiedlichen digitalen
Medien eine eindeutige Zuordnung nicht möglich.
Nutzergruppen
Digitale Bibliotheken werden von sehr unterschiedlichen Gruppen benutzt, zum Einen
von den Schöpfern von Informationen, wie z.B. Autoren, Komponisten, Photographen
und Designern, zum Anderen von den Benutzern, die nach Informationen suchen, und
schlieÿlich von den Bibliothekaren, Herausgebern und Redakteuren. In einigen Fällen gehören
Personen gleichzeitig mehreren Gruppen an.
Funktionalitäten
Abbildung 9.1 zeigt ein Modell einiger Komponenten, die in einer digitalen Bibliothek
benutzt werden. Diese haben 3 Hauptfunktionen:
• Benutzer beim Kommunizieren mit der Bibliothek helfen
• Daten speichern und
• weitere Dienste anbieten
94

9.3. KATALOGISIERUNG
Abbildung 9.1.: Komponenten einer digitalen Bibliothek
In der Regel hat eine digitale Bibliothek eine Client-Server Architektur. Benutzer greifen
mittels Computern, den Clients, auf die Bibliothek, sprich Server, zu. In einigen Fällen
sind Clients auch automatisierte Roboter, die z. B. die Bibliothek mit Daten befüllen
oder Archive und Sammlungen indizieren. Repositories sind die Server zum Speichern und
Ausliefern der gesammelten Informationen, Search Systems liefern den Benutzern Kataloge
und Indizes zum Finden von Informationen und Location Systems bieten schlieÿlich
Dienste zum Identizieren und Aunden von Informationen. In einigen Fällen kann diese
Architektur um weitere Dienste und Server erweitert werden, die entweder Kopien von
Daten spiegeln (Mirrors) oder zwischenspeichern (Cache). Ein fundamentales Problem
digitaler Bibliotheken ist die Interoperabilität zwischen den vielen verschiedenen Servern
und Clients, die mit völlig unterschiedlichen Programmen arbeiten.
Um dieses Problem zu lösen, wurden digitale Bibliothek-Standards entwickelt, um die
vielen unterschiedlichen Datenmengen einheitlich nutzbar zu machen.
9.3. Katalogisierung
Beinahe jede Bibliothek hat einen Katalog mit Einträgen aller Materialien des Archivs.
Der Katalog hilft Benutzern Materialien in der Bibliothek zu nden, stellt bibliographische
Informationen über die Objekte bereit und ist ein wichtiges Werkzeug zum Verwalten des
Archives [Arm00]. Um eine einheitliche Struktur des Katalogs zu erreichen, benötigt man
strikte Regeln, nach denen die bibliographischen Einträge erstellt werden.
So entstanden Ende der Sechziger Jahre einige wichtige Regeln zur Katalogisierung, die
auf einen Beschluss einer Konferenz in Paris 1961 basieren:
95

KAPITEL 9. EINFÜHRUNG IN DIGITALE BIBLIOTHEKEN
• AACR Anglo-American Cataloging Rules
Wird überwiegend im englisch-sprachigen Raum benutzt. Wurde 1967 verabschiedet.
• AACR2 ist die zweite Ausgabe von 1978 6
• RAK Regeln für die alphabetische Katalogisierung
Zu unterscheiden in zwei Varianten, RAK-ÖB (öentliche Bibliotheken) und RAK-
WB (wissenschaftliche Bibliotheken). Wurde 1975 verabschiedet. 7
Für die computerbasierende Speicherung und Verarbeitung von bibliographischen Einträgen
wurden weitere formale elektronische Formate entwickelt:
• MARC Machine-Readable Cataloging
Entwickelt von der Library Of Congress 8
• MAB Maschinelles Austauschformat für Bibliotheken 9
Durch die ständige Weiterentwicklung von Computertechnologien wurden auch diese Austauschformate
regelmäÿig erneuert und angepasst. So entstehen besonders durch XML
(Extensible Markup Language) seit Anfang dieses Jahrhunderts einige neue Formate wie
MarcXML, DublinCore und MABXML. Listings 9.1, 9.2 und 9.3 zeigen einige Beispiele
für diese Formate.
Listing 9.1: Beispiel: Original MARC (Ausschnitt)
&245 10|aArithmetic /|cCarl Sandburg ; illustrated as an anamorphic adventure by Ted Rand.
&260 |aSan Diego :|bHarcourt Brace Jovanovich,|cc1993.
Listing 9.2: Beispiel: MARCXML Instance (Ausschnitt)
Arithmetic /
Carl Sandburg ; illustrated as an anamorphic adventure by Ted Rand.
San Diego :
Harcourt Brace Jovanovich,
c1993.
Listing 9.3: Beispiel: Dublin Core Transformation (Gesamtes Dokument)
Arithmetic /
Sandburg, Carl, 1878-1967.
Rand, Ted, ill.
San Diego :Harcourt Brace Jovanovich,
c1993.
6 http://www.aacr2.org/
7
für weitere Informationen siehe http://www.rak-weiterarbeit.de/
8 http://www.loc.gov/marc/
9 http://www.ddb.de/standardisierung/formate/mab.htm
96

9.4. FAZIT
eng
A poem about numbers and their characteristics. Features anamorphic, or distorted,
drawings which can be restored to normal by viewing from a particular angle or by viewing the
image's reflection in the provided Mylar cone.
One Mylar sheet included in pocket.
Arithmetic
Children's poetry, American.
Arithmetic
American poetry.
Visual perception.
Eine ausführliche Beschreibung dieser Standards liefern die Texte Metadaten (siehe
Kapitel 12) und Metadatenstandards (siehe Kapitel 13).
9.4. Fazit
Wie im Text beschrieben, gibt es viele Gründe die für den Einsatz digitaler Bibliotheken
sprechen. Gerade durch die in den letzten Jahrzehnten entwickelten Technologien und
das Einführen von Standards sind einige wichtige Grundlagen geschaen worden, die eine
positive Zukunft vorausdeuten. Aber auch aus wirtschaftlicher Sicht bieten digitale Bibliotheken
viele Vorteile, um die steigenden Kosten langfristig zu senken und zu stabilisieren.
Projekte wie das 1967 von Fred Kilgour gegründete OCLC (Online Computer Library
Center) helfen fundamental beim Aufbau und der wachsenden Akzeptanz von digitalen
Bibliotheken. So beinhaltet die Datenbank des OCLC inzwischen über 35 Millionen Einträge
im MARC-Format, auf die viele Bibliotheken zurückgreifen, um mit den gleichen
Datensätzen zu arbeiten und somit ein Austauschen und Wiedernden von Dokumenten
vereinfachen.
Aber auch natürliche Bedingungen zwingen traditionelle Bibliotheken beim Umdenken,
da alte Bücher teilweise in einem schlechten Zustand sind. Eine digitale Kopie kann den
Inhalt solcher Dokumente zeitlos und überall verfügbar machen eines der Hauptziele
digitaler Bibliotheken.
97

10. Aufgaben und Formen digitaler
Bibliotheken
10.1. Probleme konventioneller Bibliotheken
Seit einigen Jahrtausenden existiert auf der Welt schon die ursprüngliche Bibliothek. Die
Aufgaben jetztiger traditionellen Bibliotheken bestehen im Auswählen, Erwerbung, Erschlieÿung,
Bereitstellung und Archivierung von Büchern und anderen Publikationsformen
wie Zeitschriften, Tonträgern, Bildmaterialien, Mikrolme. Aber heute existieren Menge
gravierende Probleme, mit der die traditionelle Bibliothek zu kämpfen hat. Hier sollen
bewuÿt nur solche Probleme genannt werden, die auch von Bibliothekaren als Probleme
anerkannt werden. Diese Probleme betreen nicht nur groÿe öentliche Einrichtungen,
sondern auch kleine private Bibliotheken. Die bekanntesten Probleme sind:
• Fehlender Stauraum für Bücher: Durch den stetigen Zuwachs an Büchern gibt
es kaum eine Bibliothek, die nicht über fehlenden Lagerraum für Bücher klagt.
• Mangelnder Platz für Leser: Dieses Problem haben besonders Bibliotheken von
Universitäten, bei denen die Anzahl der Studenten sehr stark gestiegen sind.
• Säurefraÿ an Büchern: Bei vielen Büchern, die etwa in der Zeit von 1850 bis 1950
gedruckt wurden, löst sich das Papier infolge von Säureschäden auf.
• Räumliche Entfernung für Nutzer: Der Nutzer muss zur Bibliothek hin um
diese nutzen zu können. Der Wunsch eine Bibliothek aufzusuchen nimmt mit der
Entfernung rapide ab.
• Kostenschere zwischen Anschaungen und Budgetmitteln: Die Anschaffungsbudgets
von Bibliotheken wurden weniger stark oder gar nicht angehoben; oft
sogar reduziert. Dies führte vielerorts bereits zu Abbestellungen von Büchern und
anderen Publikation.
• Konikt zwischen Breite des Bestands und akutem Bedarf: Eine konventionelle
Bibliothek besitzt nur wenige Mehrfachausgaben eines Buches. Wenn plötzlich
ein bestimmtes Thema aktuell ist, kommt es dann zu diesem Konikt.
• Aufwendiger Beschaungs- und Erschlieÿungsvorgang: Beschaung und Erschlieÿung
der neuen Publikationen sind ein sehr zeitraubender und komplizierter
Prozess.
98

10.2. AUFGABEN EINER DIGITALE BIBLIOTHEK
• Umständliche Fernleihe: 40% aller bestellten Fernleihkopien werden nicht abgeholt
und das kostet ca. 35 Millionen Euro. Eine durchschnittliche Lieferzeit ist 21
Tagen.
10.2. Aufgaben einer digitale Bibliothek
Es gibt viele Möglichkeiten um die Aufgaben einer digitalen Bibliothek zu denieren.
Jeweils durch verschiedene Standpunkten kommt es zu einer etwas anderen Gewichtung.
In diesem Abschnitt werden drei mögliche Aufgaben beschrieben.
10.2.1. Sicht heutiger Bibliotheksnutzer
Aus der Beschreibung der Probleme konventioneller Bibliotheken versteht man sofort die
Aufgaben einer digitalen Bibliothek. Einfach zu sagen:
Die Hauptaufgabe einer digitalen Bibliothek besteht darin, durch den Einsatz
digitaler Technologien Probleme konventioneller Bibliotheken zu beseitigen
oder zumindest zu reduzieren und Mehrwerte z.B. in Form neuartiger Dienste
zu schaen.
Man muss erst diese Aufgabe berücksichtigen, sonst erscheinen die alten Probleme wieder.
Das Lösen aller Probleme durch digitale Bibliotheken ist ebenfalls nicht einfach. Aber es
besteht die Chance an allen etwas zu tun. Mit technischen und organisatorischen Mitteln
kann eine völlig neue Basis geschat werden. Dies reicht aber nicht ganz, da eine auf neuer
technologischer Basis aufgebaute Lösung immer wieder neue Erwartungen und Ansprüche
schat. Durch Digitalisierung können zusätzliche Chancen wahrgenommen werden.
Eine sehr detaillierte Gegenüberstellung von konventionellen und digitalen Bibliotheken
bringen Mitchell und Strimpel [MS97]. Das Hauptmerkmal der Unterscheidung ist der
Grad der gleichzeitigen, physikalischen Präsenz von Inhalten und Nutzern. Bei den meisten
Punkten ist die digitale Bibliothek wesentlich vorteilhafter. Nur die drei letzten Punkte
verweisen auf Vorteile der konventionellen Bibliothek.
99

KAPITEL 10. AUFGABEN UND FORMEN DIGITALER BIBLIOTHEKEN
Konventionelle Bibliothek
−Hohe Kosten
−Ortsgebunden
−Feste Önungszeiten
−Groÿer Platzbedarf
−Dokumente u.U. nicht verfügbar
−Basierend auf örtlichem Bestand
−Instandhaltungs- und Ersatzprobleme
−Manuelles Indexieren und Suchen
+Originale
+Angenehm zu lesen
+Im Kontext stehend
Digitale Bibliothek
+Niedrige Kosten
+Nicht ortsgebunden
+Flexible Önungszeiten
+Geringer Platzbedarf
+Dokumente immer verfügbar
+Kann verteilte Bestände kombinieren
+Wenige Instandhaltungsprobleme
+Automatisches Indexieren &
Suchen
−Reproduktionen
−Weniger angenehm zu lesen
−Aus dem Kontext gerissen
10.2.2. Sicht der wissenschaftlichen Forschung
Viele in den Forschungsbereiche tätige Wissenschaftler benutzen Internet-basierte Dienste.
Dazu gibt es auch viele Informatiker, die sich mit dem Thema digitale Bibliotheken
beschäftigen. Die Aufgaben des Internets sollen so erweitert werden, dass die Funktion
einer Bibliothek integriert werden soll. Für diese Sichtweise wird folgende Denition von
Schmidt et al angegeben [SSNM97]:
Es ist die Aufgabe einer digitalen Bibliothek, die Ausnutzung des globalen,
vernetzten Informationsuniversums zu verbessern, mit klarer Ausrichtung auf
die Bedürfnisse des individuellen Nutzers und seiner Tätigkeit.
Diese Denition der Aufgaben spiegelt eine in der wissenschaftlichen Forschung oft vertretenden
Auassung. Vom Ausdruck Informationsuniversum bekommt man die Idee der
universellen Weltbibliothek. Eine der verbreitesten Auassungen in der wissenschaftlichen
Forschung ist, dass diese Weltbibliothek zumindest soweit aufgebaut werden muss bis sie
ohne die Mittlerfunktion von Spezialisten auskommen kann. Aber es gibt auÿer den Wissenschaftler
noch viele andere Nutzergruppen, die verschiedene Anforderungen für digitale
Bibliothek haben; das darf man nicht vergessen. Die folgende Denition kann das besser
lösen.
10.2.3. Marktwirtschaftliche Sicht
Auÿer den vorherigen Sichtweisen gibt es noch eine dazwischen liegende marktwirtschaftlich
motivierte Sichtweise, die lautet:
Es ist die Aufgabe einer digitalen Bibliothek für einem privaten, akademischen
und industriellen Nutzerkreis attraktive Produkte und eziente Dienste
100

10.3. PRODUKTE EINER DIGITALEN BIBLIOTHEK
anzubieten, die diesem helfen an das benötigte und gewünschte in digitalen
Dokumenten gespeicherte Fachwissen zu gelangen.
Hier wird eine digitale Bibliothek als eine Service-Einrichtung bedacht, die Produkte und
Dienste anbietet. Die Hauptaufgabe dieser Einrichtung ist es, die Bedürfnisse und die
Wünsche der Nutzer zu erfüllen. Nur nach dieser Nutzerorientierung kann es den Wettbewerb
bestehen. Es ist nicht nur eine Software oder ein Automat, sondern auch eine organisatorische
Einheit mit Mitarbeitern, Prozessen und technischen Hilfsmitteln. Es bietet
auch die Mittlerfunktion zwischen Anbietern (Autoren, Verlage) und Nutzern (Studenten,
Wissenschaftlern) an.
10.3. Produkte einer digitalen Bibliothek
Das konventionelle Spektrum der wissenschaftlichen Information und Kommunikation
besteht üblich aus Büchern (Monographien, Lehrbücher, Referatsorgane, Tagungsbände,
Nachschlagewerke etc.) und Zeitschriften. In der digitalen Welt ist dieses Spektrum
deutlich gröÿer. Zu digitalen Büchern, Zeitschriften kommen noch Forschungssoftware,
Datensammlungen in elektronischer Form, Visualisierungen, Animationen, Multimediaund
Hypermedia-Produkte, Elektronische Newsletter, Globale Hypertexte und verteilte
Informationssystem.
Eine digitale Bibliothek unterscheidet sich aufgrund ihrer ganz typischen Produkte von
einer konventionellen Bibliothek. Vom Internet unterscheidet sie sich aufgrund der Qualität
ihrer Produkte und der in ihrem Zusammenhang angebotenen Dienstleistungen. Die
wichtigsten Produkte einer digitalen Bibliothek sind:
• Digitale Dokumente: Sie sind die primären Produkte einer digitalen Bibliothek.
Als digitale Dokumente kann man alle Formen von nicht materiell (d.h. immateriell)
bzw. digital dargestellter Informationen verstehen. Beispiele sind Text-, Graphik-,
Audio- und Video-Dokumente.
• Metadaten: Unter Metadaten (Daten über Daten) versteht man strukturierte
Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser
aundbar gemacht wird. Im Falle von Bibliotheken sind es beschreibende Daten
zu den digitalen Dokumenten, die in ihren Kompetenzbereich fallen. Z.B. Informationen
über Titel, Autor, Thema, Aufbewahrungsort eines Dokuments, Sprache,
Beziehungen zu anderen Dokumenten etc. Durch Metadaten werden Objekte und
Informationen identizierbar gemacht. Eine typische Anwendung der Metadaten ist
ein Katalog, wobei dieser in der Regel nur Dokumente im eigenen Bestand nachweist.
Beim Suchen und Abrufen spielen Metadaten eine besonders groÿe Rolle.
Die oben genannten Produkte stammen nicht unbedingt aus dem eigenen Bestand. Im
Falle von Metadaten müssen diese selbst erstellt werden.
101

KAPITEL 10. AUFGABEN UND FORMEN DIGITALER BIBLIOTHEKEN
10.4. Dienstleistungen einer digitalen Bibliothek
Neben dem Liefern und Beschaen von Produkten können noch eine Menge von anderen
Dienstleistungen gleichzeitig angeboten werden. Die Bedürfnisse diejenigen Nutzer, die
sich wegen digitaler Dokumente an die Bibliothek wenden, bestimmen die Auswahl der
Dienstleistungen und die Kompetenzen, die die Bibliothek einbringen kann. Hier werden
einige Beispiele grob vorgestellt:
• Zugri auf ein Dokument: Statt einer normalen Lieferung von Büchern kann
dem Nutzer ein zeitlich begrenzter Zugri auf ein Dokument gewährt werden.
• Proldienst: Der Nutzer übergibt der Bibliothek ein Prol seiner Interessen (d.h.
eine Liste von Schlagwörter). Dieses Prol wird benutzt, um im festen täglich, wöchentlich
oder monatlichen Zyklus die Neuzugänge der gewünschte Recherche (ein
Katalogs oder eine bibliographischen Datenbank) auszuwählen, die zu diesen Schlagwörtern
passen. Wenn ein Titel im Katalog erscheint oder ein Eintrag in einer Datenbank
die Interessen des Nutzers entspricht, wird der Nutzer sofort z.B. durch
Email benachrichtigt.
• Durchführung von oder Unterstützung bei Recherchen: Für den Nutzer ist
das Suchen von relevanter Information oft mit groÿer Unsicherheit und mit Problemen
verbunden. Um das besser zu lösen, kann hier das Personal einer Bibliothek
beratende Unterstützung geben oder aber die Aufgabe als Ganzes übernehmen.
• Schulung im Selbst-Recherchieren: Bei groÿen Gruppen von Nutzern besteht
der Bedarf, sie in der Durchführung von selbstinitiierten Recherchen auszubilden.
• Erstellung von Thesauren und Klassikationssystemen: Thesauren und Klassikationssysteme
sind wichtige Hilfsmittel für die Beschreibung und das Suchen von
Wissensprodukten. Nur mit ihrer Hilfe ist es möglich, eine Zuordnung von Dokumenten
nach semantischen, also inhaltlichen Gesichtspunkten, zu machen. Bibliotheken
können auch hier ihre Kompetenz anbieten, um derartige Aufgaben für andere Einrichtungen
oder Firmen zu lösen.
Ein Thesaurus ist in der Dokumentationswissenschaft ein kontrolliertes Vokabular,
dessen Begrie durch Relationen miteinander verbunden sind. Bibliothekare benutzen
den Ausdruck für eine systematische Sammlung und Bearbeitung von Begrien
eines Fachgebietes. Ein Thesaurus enthält auch die Beziehungen zwischen Begrien;
nämlich Synonyme, Antonyme, Polyseme und Überbegrie.
Ein Klassikationssystem teilt das Wissen der Welt oder eines Fachgebietes in Klassen
oder in Hierarchien ein. Allgemeine Klassikationssysteme sind vielfach von
Bibliothekaren festgelegt worden. Bekannte Beispiele sind das System der amerikanischen
Kongressbibliothek (Library of Congress Subject Headings 1 ) und das
1 http://www.loc.gov/
102

10.5. ORGANISATIONSFORMEN
Dewey-System (Dewey Decimal System 2 ). Im Internet wird ebenfalls von Klassi-
kationssystemen Gebrauch gemacht, so z.B. von den Firmen Dino 3 , Excite 4 und
Yahoo 5 .
• Beratung bzgl. der Speicherung, Konvertierung und Sicherung digitaler
Dokumente: Die Kompetenz, die eine digitale Bibliothek sich auf diesem ihrem
zentralen Tätigkeitsbereich erwirbt, kann auch für Nutzer von groÿem Interesse
sein, die vielleicht nur gelegentlich ähnliche Probleme zu lösen haben.
• Persönlicher Arbeitsplatz: Durch das System und das Netz kann die Bibliothek
leicht ihre Nutzer weitere Informatik-Funktionen bieten. Ein Beispiel ist ein persönlicher
Arbeitsplatz, der Nutzern eine Software-Umgebung zur Verfügung stellt, in
der sie Textverarbeitungs-, Statistik- oder Graphikprogramme aufrufen können.
Diese Beispiele haben starke Ähnlichkeit mit den entsprechenden Dienstleistungen in einer
konventionellen Bibliothek. Daher ist es kein Zufall, sondern der Grund dafür, warum diese
Dienste früher von Bibliothekaren wahrgenommen worden. Um diese Dienste ausüben
zu können, benötigt das Bibliothekspersonal nicht nur das Wissen über Bücher, sondern
Kenntnisse über alle wissensrelevanten Medien. Z.B. Sollten die Bibliothekare die Werkzeuge
kennen, die man für das Suchen einsetzt; wissen, wie gut die Ergebnisse sind, die
sie liefern; und erkennen, wie man die Schwächen des einen Werkzeugs durch die Stärken
eines anderen kompensiert.
10.5. Organisationsformen
Die Organisationsformen der digitalen Bibliotheken lassen sich anhand verschiedener Kriterien
wie Gröÿe, Sammelschwerpunkt, Trägerschaft und Funktion unterscheiden. Die
Grenzen zwischen einzelnen Organisationsformen sind nicht immer eindeutig zu ziehen.
In diesem Abschnitt wird einige Organisationsformen kurz illustriert:
• Fachgebietsbibliothek: Wie bei Fachgesellschaften und Fachzeitschriften werden
sich Studenten und berufstätige Wissenschaftler und Fachleute immer spezieller werdenden
Fachgebieten zuwenden. Sie erwarten ihre Wissensversorgung auf ihrem Spezialgebiet
von einer Fachgebietsbibliothek. Fachgebietsbibliothek ist eine Bibliothek,
die sich bezüglich ihres Sammelschwerpunktes auf ein Fachgebiet spezialisiert hat.
Die Fachgebietsbibliothek ist in der Regel ein Teil einer anderen Einrichtung; beispielsweise
Institutsbibliotheken einer Hochschulbibliothek, Bibliotheken wissenschaftlicher
Forschungsanstalten, Archive und Museen, Bibliotheken von Vereinen, Verbänden,
Gesellschaften, Parlaments-, Behörden und Gerichtsbibliotheken oder Zentrale
Fachbibliotheken 6 .
2
Dewey war der Gründer der (inzwischen aufgelösten) Bibliotheksschule der Columbia-Universität in
New York. http://www.houston.public.lib.ga.us/Ref_deweydecimal.htm
3 http://www.dino-online.de/
4 http://www.excite.com/
5 http://www.yahoo.com/
6
Deutsche Zentralbibliothek für Medizin http://www.zbmed.de/
103

KAPITEL 10. AUFGABEN UND FORMEN DIGITALER BIBLIOTHEKEN
• Verlagsbibliothek: Die Verlagsbibliothek erfüllt eine Doppelfunktion: Zu einem
ist sie ein Verlag, in dem Autoren elektronisch publizieren und für die Distribution
ihrer Dokumente Hilfe bekommen. Zum anderen ist sie eine Bibliothek. Sie kann die
Dokumente, für die der Verlag Rechte besitzt, selbst verteilen oder aber Bibliotheken
in Lizenz geben. Einige Verlage sind fachgebietsorientiert, andere sind es nicht. Die
meisten wissenschaftlichen Verlage haben fachgebietsbezogene Schwerpunkte.
• Hochschulbibliothek: Hochschulbibliotheken sind wissenschaftliche Bibliotheken,
die primär der Literatur- und Informationsversorgung von Hochschulen in den Bereichen
Lehre, Forschung und Studium dienen. Dies geschieht insbesondere durch
Informationsvermittlung, Informationsproduktion und Unterstützung wissenschaftlichen
Lehrens und Lernens. Nachgewiesen und zur Verfügung gestellt werden sowohl
wissenschaftliche Monographien, Handbücher, Bibliographien und Fachzeitschriften,
als auch in zunehmendem Maÿe Datenbanken und andere elektronisch verfügbare
Ressourcen.
• Stadt- oder Landesbibliothek: Eine Stadtbibliothek ist eine öentliche Bibliothek,
als deren Träger (in der Regel auch Eigentümer) eine Stadt als öentlichrechtliche
Gebietskörperschaft fungiert. Im Unterschied zu den meisten anderen
öentlichen Bibliotheken, insbesondere Landesbibliotheken, ist in Stadtbibliotheken
neben Sach- und Fachliteratur auch die Unterhaltungssparte stark ausgeprägt.
Neben der Aufgabe, ihren Bürgern, Bücher oder Zeitschriften zur Ausleihe zur Verfügung
zu stellen, kann eine Stadtbibliothek auch verstärkt regional- oder stadtbezogene
Werke sammeln.
Als Landesbibliothek bezeichnet man diejenigen Bibliotheken, die für das Sammeln,
Archivieren und Bereitstellen des regionalen Schrifttums und seine Verzeichnung
in einer Bibliograe (Landesbibliographie oder Regionalbibliograe) zuständig
sind. Ein Teil der Landesbibliotheken sind gleichzeitig einem anderen Bibliothekstyp
zuzuordnen, was sich oft auch an ihren Namen ablesen lässt (z.B. Saarländische
Universitäts- und Landesbibliothek 7 , Niedersächsische Staats- und Universitätsbibliothek
Göttingen 8 ).
• Firmenbibliothek: Eine Firmenbibliothek ist die von einem Unternehmen unterhaltene
Bibliothek, die in der Regel nur rmeninternen Zwecken, der Beschaung
der für die Mitarbeiter erforderlichen Literatur, dient und öentlich nicht zugänglich
ist. Firmenbibliotheken präsentieren sich bislang so gut wie ausschlieÿlich im
rmeninternen Intranet. Groÿe Firmen wie die Siemens AG unterhalten dort sogar
eigene Virtual Libraries.
Deutsche Zentralbibliothek für Wirtschaftswissenschaften (ZBW) http://www.uni-kiel.de/IfW/
zbw/econis.htm
Technische Informationsbibliothek (TIB) http://www.tib.uni-hannover.de/
7 http://www.sulb.uni-saarland.de/
8 http://www.sub.uni-goettingen.de/
104

10.6. ERSCHEINUNGSFORM ALS WEB-PORTAL
• Privatbibliothek: Als Privatbibliothek bezeichnet man eine in Privateigentum be-
ndliche Bibliothek, die von einer Privatperson zusammengetragen wurde. Unter
Umständen können Privatbibliotheken mit Erlaubnis des Besitzers auch öentlich
zugänglich sein. Bei einer privaten Bibliothek fallen viele der Probleme weg, welche
die anderen Bibliothekstypen haben. Die bekanntesten Privatbibliotheken sind die
Bibliotheken namhafter Gelehrter und Bibliophiler (Büchersammler).
Natürlich sind auch andere Organisationsformen vorstellbar. Die Kombinationen der obigen
Beispiele sind auch möglich, damit von Fall zu Fall das Optimum erreicht wird. Es ist
sinnvoll, dass Bibliotheken über ihre Kompetenzbereiche hinweg kooperieren. Die Kooperationsstruktur
wird eine Vernetzung sein, die sich von Fall zu Fall dynamisch verändert.
Eine Vielfalt von Organisationsformen der digitalen Bibliothek sind möglich. Sie kann ein
Teil einer bestehenden Bibliothek sein oder aber eine unabhängige Neugründung. Sie kann
rein privater Natur sein, kann für die Zwecke einer Abteilung oder eines Instituts aufgebaut
worden sein, oder kann den Mitgliedern einer Fachgesellschaft oder den Einwohnern
einer Stadt zur Verfügung stehen. Eine ganz typische Realisierung kann im Rahmen einer
Hochschulbibliothek erfolgen, bei der die Nutzer, die Wissenschaftler und Studenten
aller Fachbereiche oder nur eines Fachbereichs sind. Entscheidend ist, dass die für die
Wissensgesellschaft wichtigen Dienstleistungen mit einem hohen Grad an Professionalität
erbracht werden. Welche Organisationsform dorthin führt, ist sekundär.
10.6. Erscheinungsform als Web-Portal
Für den Nutzer ist eine digitale Bibliothek eine bevorzugte Schnittstelle zu den im Netz
verfügbaren Wissensprodukten. Sie ist, um die Terminologie des Internet zu benutzen, ein
Portal, also eine Pforte zum Netz. Sie bietet einen weltweiten Zugang zu wissenschaftlichen
Informationen (über Internet/Intranet). Um die geforderten Dienste zu erbringen, bedient
sich diese Bibliothek (in Abb. 10.1 als B1 gekennzeichnet) eigener Betriebsmittel oder
greift auf andere Bibliotheken (in Abb. 10.1 als B2 bezeichnet) oder auf andere Netzdienste
zurück. Sie ist bemüht eine gewisse Beziehung zu jedem Kunden herzustellen, um in der
Lage zu sein besser als andere Dienstleister im Netz auf seine Wünsche einzugehen.
105

KAPITEL 10. AUFGABEN UND FORMEN DIGITALER BIBLIOTHEKEN
Abbildung 10.1.: Externe Einbindung einer digitalen Bibliothek
Im Normalfall wird der Nutzer digitale Dokumente elektronisch nutzen, aber das muss
nicht unbedingt so sein. Der Nutzer kann sich auch dafür entscheiden, die digitalen Dokumente
in der Bibliothek auf Papier ausdrucken zu lassen, falls sie dafür geeignet sind,
und dann an seinen Arbeitsplatz schicken zu lassen.
Die Homepage im Netz ist die Fassade einer Bibliothek. Es gibt inzwischen mehrere Bibliotheken,
die einen Zugang zum Internet haben. Ihre Homepage sind nicht alle gleich
gut gemacht. Als Beispiel sei die Homepage der Niedersächsische Staats- und Universitätsbibliothek
Göttingen 9 wiedergegeben. Sie macht einen professionellen Eindruck. Diese
Homepage verweist sowohl auf die konventionellen Abteilungen als auch auf ihre digitale
Bibliothek. Auch enthält sie Hinweise auf aktuelle Ereignisse und Veranstaltungen.
10.7. Eine mögliche technische Realisierung
Der Einsatz einer digitalen Bibliothek setzt eine moderne Informatik-Infrastruktur voraus.
Sie ist normalerweise kein zentrales System, sondern über mehrere im Netz verbundene
Rechner verteilt. Die Leistungsfähigkeit und die Ausfallsicherheit werden dadurch verbessert.
Wie in Abb. 10.2 dargestellt, stellt eine digitale Bibliothek sich den Betreibern und Nutzern
gegenüber als ein verteiltes Informatik-System dar. Ihre Struktur besteht aus einem
Client/Server-System, das über ein öentliches Netz, in der Regel das Internet, den Nutzern
seine Dienste zur Verfügung stellt. Diese Struktur ist eine Form eines verteilten
Informatik-Systems, in dem zwei Software-Komponenten zusammen kooperieren. Typischerweise
enthält der Server die Anwendungslogik und erledigt die Datenverwaltung, der
Client realisiert die Nutzungsoberäche.
9 http://www.sub.uni-goettingen.de/
106

10.7. EINE MÖGLICHE TECHNISCHE REALISIERUNG
Bei den meisten Fällen ist der Client immer ein Web-Client und der Server immer ein
Web-Server. Damit gibt es für beide starke Beschränkungen, aber auch groÿe Vorteile.
Einerseits ist die Art der Interaktion durch die Web-Protokolle (wie z.B. HTTP, HTT-
PS etc.) beschränkt. Andererseits kann derselbe Client im Prinzip auf alle an das Web
angeschlossene Server zugreifen.
Abbildung 10.2.: Struktur einer digitalen Bibliothek
Ein Bibliothekssystem hat groÿe Ähnlichkeit mit anderen Informatik-Systemen. Es wird
durch vier Aspekte charakterisiert; nämlich Daten, Geräte, Software und organisatorische
Maÿnahmen.
• Daten: Als eigene Daten des Bibliotheks-Servers gelten zu einem der Bestand an
Dokumenten, den er vorhält, die beschreibenden Daten (sog. Metadaten), über die
er verfügt, sowie die für den Betrieb erforderlichen administrativen Daten (Nutzer,
Lieferanten, Bestellungen, Abrechnungen).
• Geräte, Nutzerseite: Die Schwerpunkte liegen auf der Ausstattung des Rechners
am Arbeitsplatz und den Eigenschaften des Netzanschlusses.
Leistungsfähige PCs oder Arbeitsplatzrechner: Für den Nutzer sollten die Zugrie
auf angebotene Dokumente möglich sein, ohne den Arbeitsplatz verlassen
zu müssen. Um Text-, Graphik-, Audio-, Video-Dokumente benutzen zu können,
müssen Farbbildschirm, Lautsprecher, evtl. Drucker vorhanden sein.
Anschluss an das interne oder externe Netz: Hier liegt bei vielen Firmen, aber
vor allem bei privaten Nutzern, der Engpass. Für eine sinnvolle Nutzung ist
ein ISDN-Anschluss (64 Kbit/s) die untere Grenze.
• Geräte, Bibliotheksseite: Gegenüber den Arbeitsplätzen der Nutzer sind hier die
Anforderungen deutlich höher. Folgende Voraussetzungen müssen fast immer erfüllt
sein:
107

KAPITEL 10. AUFGABEN UND FORMEN DIGITALER BIBLIOTHEKEN
Leistungsfähige PCs oder Arbeitsplatzrechner: Der für den Server-Betrieb bediente
Rechner muss mit ausreichendem Speicher- und Verarbeitungskapazität
versehen sein. Durch Auslagerung von Aufgaben auf andere Rechnern im Netz
kann die Speicher- und Verarbeitungskapazität ausgeglichen werden. Auÿerdem
ist für die Datensicherung ein Bandlaufwerk notwendig.
Interne Vernetzung: In einer internen Umgebung (z.B. innerhalb einer Firma
oder eines Instituts) hängen Server und Arbeitsplatzrechner meist an einem
lokalen Netz (LAN). Sowohl beim Ethernet als auch beim Tokenring liegt die
Leitungskapazität bei 100 MBit/s; das ist für die meisten Fälle ausreichend.
Anschluss an das externe Netz: Gegenüber kleine Firmen und Haushalte verfügen
die groÿen Anbieter z.B. Universitätsinstitute fast immer über sehr leistungsfähige
Anschlüsse (100MBit/s und mehr).
• Software: Im Bereich der Software-Komponenten sollten die Nutzer- und Bibliotheksseite
gleichwertig behandelt werden. Der Betreiber der Bibliothek muss sich
Gedanken über beide Seiten machen.
• Organisatorische Maÿnahmen des Betreibers: Auÿer der oben genannten drei
Aspekte sind organisatorische Maÿnahmen (man spricht auch von Orgware) für eine
Informatik-Anwendung auch sehr wichtig.
Dienstleistungs-Bereitschaft: Die Nutzer einer elektronischen Bibliothek stellen
sehr hohe Anforderungen bezüglich der Verfügbarkeit und der Nutzbarkeit des
Systems. Eine Verfügbarkeit rund um die Uhr ist der Maÿstab. Der Zugri
zu den Diensten muss einfach sein und die Reaktionszeit des Systems deutlich
unter der Sekundenschwelle liegen, sonst wird es als Belastung empfunden und
gemieden.
Sicherung der Daten und Dienste: Die vorhandenen Dokumente in einer digitalen
Bibliothek stellen ein hohes Investment dar. Deren Verlust wäre inakzeptabel.
Denn deren Wiederherstellung wäre mit sehr hohen Kosten und Zeitverlusten
verbunden. Deswegen sind regelmäÿige Datensicherungen und ausgetestete
Wiederherstellungsverfahren von groÿer Bedeutung. Die Verfügbarkeit
der Dienste muss gesichert werden, weil lange Ausfallzeiten für die Nutzer zu
Problemen führen können.
Schutz-Maÿnahmen: Internet ist ein unsicheres öentliches Netz. Jedesmal wenn
aus dem internen Netz einer Firma heraus auf ein Internet-Angebot zugegriffen
wird, müssen Vorkehrungen wie Passwörter, Virenschutz und elektronische
Brandmauern (Firewalls) als Voraussetzung bestehen. Man will eigene Dokumente
möglichst auch nur der gewünschten Zielgruppe zur Verfügung stellen.
Je nach unterschiedlichen Situationen gibt es verschiedene Sicherheitspolitiken.
108

10.8. FAZIT
10.8. Fazit
In dieser Ausarbeitung werden mehrere Sichten einer digitalen Bibliothek (wie z.B. Aufgaben,
Produkte, Dienstleistungen, Organisationsformen etc.) detailliert erläutet. Aber
diese beschriebenen Inhalte basieren nur auf denen zur Zeit zugreifbaren Technologien.
Die Zukunft der Bibliothek könnte auch ganz anders aussehen, da viele externe Faktoren
wie neue Technologien oder neue Anforderungen auf die zukünftige Bibliothek einwirken.
109

11. Verteilte und förderierte digitale
Bibliotheken
11.1. Einleitung
In den letzten Jahren haben digitale Bibliotheken zunehmend an Bedeutung gewonnen.
Digitale Bibliotheken ermöglichen den Zugri einer Vielzahl von Benutzern auf groÿen
Mengen digitaler Dokumente der verschiedensten Medientypen (z.B. Texte, Videolme,
Musik, Bilder, usw.).
11.1.1. Digital Bibliothek
Teilweise werden Digitale Bibliotheken auch virtuelle Bibliotheken genannt. Eine Virtuelle
Bibliothek, auch Online Bibliothek, bietet Literaturinformationen und Literatur elektronisch
über das Internet. Das Älteste Beispiel ist die www-virtual library vom Ernder des
WWW. Freiwillige Experten auf der ganzen Welt pegen einzelne Fachgebiete und stellen
auf Grund bestimmter Qualitätsanforderungen Listen von Links zu informativen Webseiten
ins Netz. Im Gegensatz zur virtuellen Bibliothek, die nur digitale Objekte nachweist,
bezieht die Digitale Bibliothek neben den Digitalen Objekten alle Objekte einer existierenden
Bibliothek mit ein. Die elementarsten Eigenschaften von digitalen Bibliotheken
bestehen darin, dass sie elektronische Dokumente beliebigen Typs (z. B. Text-, Graphik-,
Audio- oder Video-Dokumente) verwalten bzw. Bereitstellen. Der Zugri durch den Nutzer
auf die bereitgestellten Dienste einer digitalen Bibliothek wird über HTML-basierte
Webseiten ermöglicht. Daher ist nahezu jede digitale Bibliothek über einen konventionellen
Web-Browser zugreifbar. Eine vollständige Digitale Bibliothek hat die Funktionen
einer traditionellen Bibliothek wie Sammeln,Auswählen, Erschlieÿen, Aufbereiten für die
Benutzung und Archivierung.
11.1.2. Verteilte bzw. föderierte digitale Bibliotheken
Eine verteilte digitale Bibliothek ist eine digitale Bibliothek, die aus mehreren Dokumentenspeichern
zu einem Gesamtsystem vereint wurde. Und diese sind über ein Netzwerk
verbunden. Die verteilte Bibliothek wird verwendet, um in einem Netzwerk vorhandene
Dokumente für alle Benutzer leicht zugänglich zu machen. Eine Beispiel ist NZDL
(http://www.sadl.uleth.ca/nz/cgi-bin/library), die eine Zusammenstellung mehrerer
verschiedener Kollektionen digitaler Dokumente ist. Ein anderes Beispiel ist NCSTRL
(http://www.ncstrl.org/), die ein Zusammenschluss von Institutionen (vor allem Hoch-
110

11.2. VORGEHENSWEISEN ZUR FÖDERATION VON DIGITALEN BIBLIOTHEKEN
schulen) ist. Die digitale Bibliotheken bilden einen Zusammenschluss gleichartiger Softwaresysteme.
Bei einer föderierten digitalen Bibliothek handelt es sich ebenfalls um ein verteiltes Gesamtsystem.
Hier sind die einzelnen Dokumentenspeicher allerdings vollständig autonome
digitale Bibliotheken. Diese Systeme behalten ihre unterschiedlichen Eigenschaften. Daher
ist ein Aufbau eines Zusammenschlusses aufwendiger als bei gleich gearteten Systemen
bzw. Komponenten.
11.2. Vorgehensweisen zur Föderation von digitalen
Bibliotheken
Es gibt verschiedene Ansätze zur Föderation von digitalen Bibliotheken unterhalb eines
Portals. Dabei wären prinzipielle zwei Vorgehensweisen denkbar.
Zunächst werden viele föderierte digitale Bibliotheken als ein einziges Gemeinsamsystem
in das Portal integriert. Dann können die föderierten digitalen Bibliotheken innerhalb
des Portals zusammenführt werden. Ein externes System müsste in das Portal integriert
werden. Bei der Föderation der digitalen Bibliotheken kann man auf extierende Konzepte
zurückgegreifen. Daher wäre die Integration digitaler Bibliotheken innerhalb eines Portals
auf relativ einfacher Art durchzuführen. Die föderierte digitale Bibliothek würde alle
einzelnen am Zusammenschluss beteiligten Dokumentenquellen kapseln und dem Portal
eine einheitliche Zugrisschnittstelle bereitstellen.
Bei der anderen Vorgehensweise könnte das Portal selbst als föderierende Instanz beim
Zusammenschluss der zu integrierenden digitalen Bibliotheken auftreten. Daher ist ein
direkter Zugri auf die Dienste und die Inhalte der einzelnen an der Föderation beteiligten
Dokumentenquellen sichergestellt. Diese beiden Vorgehensweisen sollte man zur
Integration von digitalen Bibliotheken innerhalb eines Portals bevorzugen.
11.3. Prinzipieller Ansatz zur Föderation digitaler
Bibliotheken
Bei der föderierten digitalen Bibliothek handelt es sich um ein föderiertes Informationssystem.
Daher können wir auf das Wissen über föderierter Datenbanksysteme aufbauen
und für föderierte digitale Bibliotheken nutzen. Die grundlegenden Dienste von digitalen
Bibliotheken, wie Recherche nach und Zugri auf Dokumente, müssen bei der Integration
im Portal auch auf das Portal übertragen werden. Aus diesem Grund ist auch das Portal
als föderiertes Informationssystem zu betrachten. Die Basis eines Informationssystems ist
normalerweise ein DBMS. So können wir über verschiedene DBMS-Architekturen eine
Portal-Architektur entwickeln auf der Grundlage föderierte DBS.
111

KAPITEL 11. VERTEILTE UND FÖRDERIERTE DIGITALE BIBLIOTHEKEN
11.3.1. 5-Ebenen-Schema-Architektur
Übertragen auf die Integration von digitalen Bibliotheken in einem Portal ist die globale
Sicht erforderlich, um einheitliche Anfragemöglichkeiten bei Recherchen sowohl im
Portal-eigenen Content-Repository als auch in den externen Systemen für den Nutzer zu
garantieren.
Die 5-Ebenen-Schema-Architektur ist eine mögliche Ausprägung der allgemeinen Föderationsstruktur
aus Abbildung 11.1. Es bietet eine globale Sicht in Form eines globalen (föderierten)
Datenschemas. Mit den darauf basierenden externen Schemata können Sichten
auf den integrierten Gesamtdatenbestand aller an der Föderation beteiligten Datenquellen
deniert werden. Für Recherchen besteht daher keine Möglichkeit auf lokalen konzeptionellen
Schemata zurück zugreifen. Suchanfragen werden also in einheitlicher Form auf
den externen Schemata durchgeführt, eine Transparenz bzgl. der externen Datenquellen
ist somit sichergestellt.
Abbildung 11.1.: 5-Ebenen-Schema-Architektur
Allerdings ist der Ansatz der 5-Ebenen-Schema-Architektur nicht als Portal-Architektur
zu benutzen, denn der Zugri auf eine digitale Bibliothek entspricht nicht dem direkten
Zugri auf ein DBMS. Das System kapselt das DBMS und erlaubt nur strikt reglementierte
Zugrie über entsprechende Schnittstellen. Diese Schnittstellen stellen eine Sicht,
die durch die Vorgabe von Suchattributen und Rechercheoperationen bestimmt werden,
bereit. Die Zugangsschnittstellen sind wegen den verschiedenen digitalen Bibliotheken
unterschiedlich gestaltet. Diese wiederum unterliegen allerdings unterschiedlichen Datenmodellen.
Dies widerspricht der Forderung, dass die Exportschemata im Rahmen einer 5-
Ebenen-Schema-Architektur durch ein einheitliches Datenmodell beschrieben sein sollen.
Wir sollen die verschiedenen Exportschemata (also Schnittstellen) in einer einheitlichen
Form darstellen, um dieses Problem zu lösen.
112

11.3. PRINZIPIELLER ANSATZ ZUR FÖDERATION DIGITALER BIBLIOTHEKEN
11.3.2. Mediator-Wrapper-Prinzip
Mediator-Wrapper-Prinzip ist ein entsprechende und sehr viel benutzt Ansatz zur Integration
von digitalen Bibliothek. Ein Wrapper ist ein Tool zur Extraktion von Daten
aus einer Server-Datenbank. Dazu wird eine spezizierte Abfrage (Query) an die Server-
Schnittstelle der jeweiligen Website geschickt, aus der Daten entnommen werden sollen.
Ein Mediator dient als Schnittstelle zwischen den abgesendeten und extrahierten Daten
des Wrappers und der Datensicht des Programms. Das heiÿt, in der Mediator-Wrapper-
Logik werden zunächst die vom Nutzer eingegebenen Parameter (wie Reisezielort, Datum
und Preis) an den Mediator gesandt, der die Daten so formatiert, dass sie vom Wrapper
an die jeweiligen Server gesendet werden können. Anschlieÿend sendet der Wrapper die
gesuchten und entsprechend extrahierten Daten (z.B. die konkreten Flugdaten) an den
Mediator zurück.
Die folgende Abbildung 11.2 ist ein charakteristischer Anwendungsfall für mediator-basierte
Informationssysteme.
Abbildung 11.2.: Systemskizze für DL-integriertes Portal auf Basis des Mediator-Wrapper
Bei diesen Anwendungsfall besteht nur die Möglichkeit auf eine Föderation von Nicht-
Datenbanksystemen ausschlieÿlich lesende Zugrie durchzuführen mit eingeschränkten
Anfragen. Da der Zugri auf eine digitale Bibliothek nicht mit dem Zugri auf ein DBMS
gleichzusetzen ist, kann der Zusammenschluss von digitalen Bibliotheken unter einem
Portal als Föderation von Nicht-Datenbanksystemen betrachtet werden. Wir können das
Mediator-Wrapper-Prinzip als ein Grundprinzip für entwickelnde Portal-Architektur benutzen.
Im folgende Abschnitt wird die Anwendung des Mediator-Wrapper-Prinzips im
Rahmen konkreter Ansätze betrachtet.
113

KAPITEL 11. VERTEILTE UND FÖRDERIERTE DIGITALE BIBLIOTHEKEN
11.4. Verschiedene Architekturansätze
Das Mediator-Wrapper-Prinzip ist eine grundlegende und abstrakte Vorlage für Systemarchitekturen,
um verschiedene Komponenten (z.B. digitale Bibliotheken) zu einem Gesamtsystem
zusammenzuführen. Aber nicht in jedem Anwandungsfall sind die Komponenten
als Mediator bzw. Wrapper zu bezeichnen. Ein oder mehrere Komponenten
als Middleware bieten eine einheitliche, übergreifende Sicht auf die verschiedenen Teilsysteme
an. In diesem Fall können wir eine solche Middleware als Mediator bezeichnen.
Für jedes anzubindende Teilsystem muss eine Schnittstellenkomponente vorhanden sein,
um die spezische Schnittstelle des Teilsystems zu kapseln und an den Mediator zu binden.
Diese Komponenten transformieren einheitliche Zugrie des Mediators in die spezi-
sche Form des gekapselten Teilsystems und fungieren somit als die Verbindung zwischen
dem Gesamt- und den Teilsystemen. Die Schnittstellenkomponenten können allgemein als
Wrapper bezeichnet werden. In dem folgenden Abschnitt werden die konkreten Ansätze
auf der Grundlage der Mediator-Wrapper-Prinzips erklärt.
11.4.1. InfoBus
Der InfoBus stellt ein Bussystem dar, über das alle Komponenten miteinander kommunizieren.
Die Zusammenarbeit der Komponenten geschieht über wenige Schnittstellen,
wodurch für eine geringe Komplexität gesorgt wird. Die Kommunikation läuft asynchron
und symmetrisch ab.
Hierbei handelt es sich um eine auf CORBA basierende verteilte Objekt-Infrastruktur (Sehen
Sie die Abbildung 11.3). CORBA, die Common Object Request Broker Architecture,
war eine Antwort auf die starke Zunahme von Hardware- und Software-Produkten. Ziel
war es, eine Middleware zu schaen, welche eine orts-, plattform- und implementationsunabhängige
Kommunikation zwischen Applikationen erlaubt. Die CORBA-basierte Middleware-Technologie
wird durch einen hohen Grad an Flexibilität ausgezeichnet. Im Rahmen
dieser Infrastruktur werden sämtliche Objekte (Dokumente, Dienste, Informationsquellen)
in Form von CORBA-Objekten repräsentiert, die durch DLIOP (Digital Library
Interoperability Protocol) kommunizieren. Es ist hier relativ einfach möglich, neue Funktionalitäten
nachträglich zu integrieren.
114

11.4. VERSCHIEDENE ARCHITEKTURANSÄTZE
Abbildung 11.3.: InfoBus
Library Services (LS), CORBA-Objekte, repräsentieren eine interne Systemfunktionalität,
wie sie z.B. für die Verwaltung von Dokumenten und Metadaten erforderlich ist.
Darüber hinaus interagieren LS-Objekte mit Library Service Proxies (LSP), die Stellvertreter
innerhalb des InfoBus für externe Systeme, wie z. B. digitale Bibliotheken, darstellen.
Die LSP-Objekte kapseln somit die externen Informationsquellen und fungieren
in diesem Konzept als Wrapper. Durch das Hinzufügen neuer LS-Objekte kann man die
Funktionalität des Systems vereinfachen. Und durch die Integration der LSP-Objekte in
die Infrastruktur können leicht neue digitale Bibliotheken in der Föderation hinzugefügt
werden.
11.4.2. eVerlag
Das eVerlag-System ist als ein hochgradig verteiltes System konzipiert worden. Es handelt
sich um eine Weiterentwicklung der digitalen Bibliothek MeDoC(Multi Experiment
Data and Operations Center). eVerlag-System-Architektur kann auch als Beispiel für eine
Umsetzung des Mediator-Wrapper-Prinzips herangezogen werden.
Das eVerlag-System besteht im wesentlichen aus drei Komponenten: Useragent, Centralagent
und Provideragent.
115

KAPITEL 11. VERTEILTE UND FÖRDERIERTE DIGITALE BIBLIOTHEKEN
Abbildung 11.4.: eVerlage-Architektur
Useragenten bilden die Zugrisschnittstelle der User auf das System. Ihre Hauptaufgaben
bestehen aus der Kapselung von Zugangscharakteristiken und dem Cachen von bestimmten
Daten, um einen performanten Zugri auf das System gewährleisten zu können. Für
den Zugang zum eVerlag-System bieten unterschiedliche Ausprägungen von User-Agents
verschiedene Arten von Schnittstellen an. Hierbei setzt man auf eine HTML-Basierte
Benutzungsschnittstelle. Der User kann über einen Web-Browser auf die Informationen
zugreifen. Die weiteren Useragenten und dessen Systemschnittstellen kann man für die
Anbindung anderer Softwaresysteme zur Verfügung stellen. Auf diese Weise lieÿe sich
auch eVerlage in eine Föderation mit anderen digitalen Bibliotheken integrieren.
Die zentrale Komponente innerhalb der eVerlag-Architektur ist der Zentralagent, der zwischen
Useragent und Provideragent vermittelt. Der Zentralagent besteht aus sieben Managern:
Usermanager, Agentmanager, Groupmanager, Oeringmanager, Orderingmanager,
Plamentmanager und Licencemanager. So ein Manager übernimmt alle grundlegenden
Verwaltungsaufgabe.
Das eVerlag-System selbst sieht in seiner verteilten Architektur allerdings auch selbst die
Anbindung mehrerer Dokumentenquellen vor, welche durch Provider-Agents repräsentiert
werden. Der Provideragent ist die dokumentenverwaltende und dokumentenliefernde
Komponente des eVerlag-Systems. Seine wichtigste Aufgabe besteht darin, das Datenbanksystem
zur Speicherung des Dokumentenbestandes vom übrigen System zu kapseln.
Anfragen, die Dokumente betreen, werden vom Useragenten an den Provideragenten
116

11.4. VERSCHIEDENE ARCHITEKTURANSÄTZE
geschickt, ausgewertet und die Ergebnisse wieder zurück geliefert. Bei diesem Fall wird
der Zentralagent als Mediator bezeichnet. Die Provideragenten übernehmen die Aufgaben
von Wrappern.
11.4.3. OMNIS/2
Bei einem OMNIS/2-System handelt sich viel mehr um ein System, welches mehrere
verschiedene digitale Bibliotheken auf einer Metaebene zusammenfasst, um zusätzliche
übergreifende Funktionalität bei der Nutzung der angebundenen digitalen Bibliotheken
bereitstellen zu können.
Abbildung 11.5.: OMNIS/2-Architektur
Ein Kernpunkt von OMNIS/2 ist, dass weder die eingebundenen digitalen Bibliothekssysteme,
noch die gespeicherten Dokumente geändert werden müssen. Die Dokumente können
dabei in ihren ursprünglichen Systemen verbleiben und müssen nur eindeutig aundbar
sein. Wir verwenden dabei eine serverseitige Anbindung der OMNIS/2-Datenbank unter
Verwendung von Java- Servlets und einer JDBC-Kopplung. Dabei wird ein Webserver
mit Hilfe der Servlets zu einem vollständigen Applikationsserver, also dem vollständigen
OMNIS/2-Kernsystem, ausgebaut.
Die Anbindung der externen digitalen Bibliotheken erfolgt serverseitig durch Komponenten,
die Bestandteil des Servlets sind und von deren selbst digitale Bibliothek existieren.
Diesen Komponenten übernehmen die Transformation von Suchanfragen in die jeweils
spezischen Formate der angebundenen Systeme und nehmen die Anfrageergebnisse entgegen,
die dann im OMNIS/2-System weiterverarbeitet werden. Darauf wird das Ergebnis
durch ein entsprechend Format zum Browser zurück geliefert. Daher kann diesen Servlet-
Komponenten die Funktion von Wrappern zugeschrieben werden. Das Kernsystem, welches
die Komponenten integriert, ist dann als Mediator zu bezeichnen.
117

KAPITEL 11. VERTEILTE UND FÖRDERIERTE DIGITALE BIBLIOTHEKEN
11.4.4. BlueView
BlueView steht für BlueRose Virtual Integration of Electronic Web Sources und ist
in BlueRose, ein zum Teil vom BMBF (Bundesministerium für Bildung und Forschung)
gefördertes Projekt, integriert. Im BlueView Projekt der Universität Rostock werden Digitale
Bibliotheksdienste basierend auf der Architektur von virtuellen Dokumentenservern
(VDS) entwickelt. BlueView kann auch für den Aufbau verteilter oder föderierter digitaler
Bibliotheken verwendet werden.
Mit Standardtools wie Volltextdatenbanken, Information-Retrieval- Systemen, objektrelationalen
Datenbankmanagementsystemen und Replikations- und Caching-Diensten werden
verschiedene heterogene lokale Dokumentenserver (LDS) in einem Virtuellen Dokumentenserver
vereint.
Abbildung 11.6.: Der Virtuelle Dokumentenserver der BlueView-Architektur
Virtuelle Dokumentenserver lieferen eine homogene Sicht auf eine heterogene Reihe lokaler
Dokumentenquellen. Der Query-Server als ein Mediator verteilt die Rechercheanfragen
an die verschiedenen LDS(z.B. DBMS, Filesysteme oder lokale digitale Bibliotheken).
Wrapper kapseln die jeweils spezischen Schnittstellen der LDS, daher bieten Wrapper
einheitliche Recherche und Zugrismöglichkeiten. Der VDS mit Hilfe des Replication-
Service speichert die Zugrie über die Wrapper in einem lokalen Cache ab, um auf den
Query-Server direkt zu zugreifen. Mit Hilfe dieser VDS können unter anderem lokale
Dokumente und die assoziierten bibliographischen Metadaten verwaltet und durchsucht
werden. Nicht lokal gespeicherte Dokumente können repliziert werden, um den Zugri zu
beschleunigen und die Verfügbarkeit zu erhöhen.
Da mehrerer LDS auf der Grundlage eines VDS bereits als eine verteilte digitale Bibliothek
realisiert werden kann, sieht BlueView VDS-Architektur auch die Föderation mehrerer
VDS vor, wodurch Dokumentenrecherchen und -zugrie auch auf weitere (externe)
Dokumentenquellen ausgeweitet werden kann.
118

11.4. VERSCHIEDENE ARCHITEKTURANSÄTZE
11.4.5. DAFFODIL
Abschlieÿend soll ein Ansatz von Distributed Agents for User-Friendly Access of Digital
Libraries (DAFFODIL) beschrieben werden. DAFFODIL stellt ein agentenbasiertes
Zugangssystem für digitale Bibliotheken dar, dessen Fundament durch die im Internet
verfügbaren digitalen Bibliotheken gebildet wird. Zugri zu diesen wesentlichen Elementen
DAFFODILs wird durch den Einsatz von Wrappern geschaen. Die verschiedenen
Rechercheebenen erstrecken sich von einfachen elementaren Suchoperationen (sog. Moves)
über komplexere Kombinationen dieser Moves (sog. Tactics und Stratagems) bis hin
zu aufwendigen Suchstrategien (Strategies).
Abbildung 11.7.: DAFFODIL-Architektur
Die DAFFODIL-Architektur besteht aus vier Komponenten. Die unterste Ebene besteht
aus den digitalen Bibliotheken, die über ein Adapter angesprochen werden. Diese werden
auf der darüber liegenden Ebene durch Wrapper-Agenten gekapselt und für das Gesamtsystem
nutzbar gemacht. Das Kernsystem von DAFFODIL wird von der dritten Schicht
gebildet. Innerhalb des Kernsystems stellte jede Ebene ihre Funktionen sowohl den anderen
Komponenten des Systems, als auch dem Benutzer zur Verfügung. Genutzt werden im
Wesentlichen die Agenteneigenschaften Kommunikationsfähigkeit, Adaptivität und Autonomie.
Die Moves sind durch die Adapter zu den Informationsquellen implementiert. In der
Ebene der Tactics werden Dienste der einzelnen Bibliotheken zu höheren Diensten aggregiert,
beispielsweise zu einem Datenquellen übergreifenden Dienst zur Co-Autorensuche.
Stratagems bilden einen strategischen Teilprozess der Recherche ab, bei dem erschöpfend
nach bestimmten Aspekten gesucht wird, beispielsweise Aggregation Browse - Browsen
119

KAPITEL 11. VERTEILTE UND FÖRDERIERTE DIGITALE BIBLIOTHEKEN
von Journal und Konferenzhierarchien nach allen Artikeln zum gesuchten Thema. Strategies
fassen Aktionen auf den Ebenen Moves, Tactics und Stratagems zu einem zum
Benutzerprol passenden Rechercheplan zusammen. Der Systemzugang für den Nutzer
wird durch einen User-Interface-Agenten ermöglicht.
Die komplexeren Recherchemechismen (Tactics, Stratagems, Strategies) unterstützen sich
auf den elementaren Moves. Daher agieren diese Recherchemechismen direkt auf den Suchoperationen
der angeschlossenen digitalen Bibliotheken. Die für die Umsetzung der Moves
konzipierten Agenten interagieren somit mit den Wrapper-Agenten und übernehmen die
Koordination der Zugrie. Daher kann den auf dieser (internen) Ebene angesiedelten
Agenten die Funktionalität eines Mediators zugeschrieben werden.
11.5. Wrapper
Die Wrapper kapseln die Informationssysteme, um eine einheitliche Schnittstelle auf beliebige
Informationssysteme zu bieten und die Besonderheiten der Systeme zu vereinheitlichen.
Es existiert verschiedene Möglichkeiten (standardisierte Schnittstellen, API, Web-Schnittstelle),
um auf eine digitale Bibliothek zuzugreifen.
Die Nutzung standardisierter Schnittstellen ist i. d. R. nur bei kooperierenden digitalen
Bibliotheken möglich, da die entsprechende Betreiberorganisation für einen zugreifenden
Client (Wrapper) einen autorisierten Zugang einrichten muss. Es kann öentlichen Zugänge
anbieten, allerdings ist ein Zugri auf die Volltexte der Dokumente unmöglich, sondern
man erhält nur bibliographische Informationen.
Wenn ein Wrapper auf ein API aufsetzt, muss individuell für dieses API implementiert
werden. Da der Umfang an Dokumentation bei diesem Fall weniger stark als bei weit
verbreiteten Standards der Fall ist und auch kaum eine Referenzimplementierung erwartet
werden kann, ist der Implementierungsaufwand hier höher einzuschätzen.
Bei einer nicht kooperierenden digitalen Bibliothek bleibt häug die Web-Schnittstelle als
einzige Zugrismöglichkeit. Die Web-basierten Wrappern setzen direkt auf diesen Web-
Schnittstellen auf und nutzen diese Form des Zugangs, indem sie die von der digitalen
Bibliothek ausgelieferten HTML-Seiten interpretieren und die darin kodierten Informationen
extrahieren.
11.6. Fazit
Zur verteilten bzw. föderierten digitalen Bibliotheken sind zunächst die Vorgehensweise
und der prinzipielle Ansatz zu erklären. Wegen der Grundfunktion der digitalen Bibliothek,
wie Recherche nach und Zugri auf Dokumente, können wir die verteilte bzw.
föderierte digitale Bibliotheken als ein föderiertes Informationssystem bedenken. Dabei
wird das Mediator-Wrapper-Prinzip als der am besten geeignete Ansatz bedacht, um verschiedene
digitale Bibliotheken zu einem Gesamtsystem zusammenzuführen. Anschlieÿend
wurde anhand einiger Beispiele InfoBus, eVerlage, OMNIS/2, BlueView und DAFFODIL
120

11.6. FAZIT
vorgestellt. Um jedoch eine Architektur für die Integration mehrerer verschiedener digitaler
Bibliotheken ableiten zu können, muss eine übergreifende Sichtweise eingenommen
werden. Jedes System besitzt Komponenten zur Kapselung und Anbindung der zu föderierenden
digitalen Bibliotheken. Dafür muss man auf jeden Fall eine oder mehrere Komponenten
für die Zugrie auf die digitalen Bibliotheken anpassen. Die Wahl der geeigneten
Schnittstelle richtet sich nach der von ihr bereitgestellten Funktionalität und bestimmt
die Art des Wrappers, der zur Anbindung der digitalen Bibliothek darauf aufsetzt.
121

12. Metadaten
12.1. Denition
Wörtlich genommen sind Metadaten Daten über Daten. Dies ist allerdings mehr eine
Übersetzung des Begris denn eine Denition. Etwas genauer ist die Aussage, Metadaten
seien the sum total of what one can say about any information object at any level of
aggregation[GGSB98, S. 1]. Ein information object ist in diesem Zusammenhang alles,
egal welcher Form oder welchen Zustands, was gefunden und verändert werden kann. Ein
Objekt kann z.B. sowohl ein Buch, ein Bild, ein archäologisches Fundstück, Software oder
Klausurergebnisse sein. Metadaten sind strukturierte Ressourcenbeschreibungen. Dabei
gibt es keinerlei Vorschriften über die Art der Ressourcen und ebensowenig über die Art
der Metadatenstruktur oder der -aussage. Weder die Ressource noch die Informationen
darüber müssen digitaler oder textueller Natur sein. Metadaten gibt es nicht erst seit dem
Computerzeitalter und nicht nur über Bücher, auch wenn (Online-)Bibliothekskataloge
bekannteste Anwendungen sind.
Allen Objekten gemeinsam sind drei Eigenschaften, die sich durch Metadaten wiederspiegeln
lassen:
• Inhalt - eine intrinsische Information darüber, was das Objekt enthält oder wovon
es handelt
• Kontext - Informationen über die Entstehung des Objekts(extrinsisch)
• Struktur - bezeichnet die formalen Assoziationen innerhalb eines Objekt(intrisisch)
oder von Objekten untereinander(extrinsisch)
Das Allgemeine ist sowohl Stärke und Schwäche der Metadaten. Es erlaubt die Anwendung
in zahllosen Fällen, macht einen einheitlichen Gebrauch aber nahezu unmöglich. Wenn
z.B. das Datum Format gefragt ist, kann das je nach Kontext mit Aussagen wie 20x30
cm oder pdf-Datei belegt sein. Um mit Metadaten arbeiten zu können, ist es nötig,
Regeln für jedes Einsatzgebiet festzulegen. Allerdings ist es auch in Teilgebieten noch
schwierig genug, sich auf einheitliche und verbindliche Standards zu einigen.
12.2. Kategorien
Metadaten werden oft mit der Beschreibung des zugrunde liegenden Objekts gleichgesetzt,
aber there is more to metadata than description[GGSB98, S. 3]. Es lassen sich
zusätzliche Informationen speichern, die den Umgang mit dem Objekt erleichtern (oder
122

12.2. KATEGORIEN
erst ermöglichen) und die nicht aus dem Objekt selbst erschlossen werden können, wie
z.B. der Fundort einer altgriechischen Scherbe. Metadaten lassen sich in fünf Kategorien
einteilen, die in den nächsten Unterkapiteln kurz erläutert werden sollen:
• administrative
• deskriptive
• der Erhaltung dienende
• technische und
• die Nutzung betreende Metadaten
12.2.1. Administrative Metadaten
Unter administrativen Metadaten versteht man alle Informationen zu einem Objekt, die
zum managen und verwalten nötig sind. So kann (und sollte wohl auch)z.B. zu jedem Buch
in einer Bibliothek gespeichtert werden, wann es angeschat wurde, in welchem Regal an
welcher Systemstelle es zu nden ist, ob es ausgeliehen werden kann u.ä.
12.2.2. Deskriptive Metadaten
Deskritptive Metadaten sind inhaltliche Beschreibungen und alle Daten, die zur Identizierung
eines Informationsobjekts nötig sind. Darunter fallen Katalogeinträge, Abstracts,
Schlagwortindices, aber auch Kommentare von Benutzern, selbsterklärende Hilfen für den
unmoderierten Zugri auf ein Objekt oder Inhaltsverzeichnisse.
12.2.3. Erhaltungsdienliche Metadaten
Diese Art der Metadaten dokumentiert den physischen Zustand eines Objekts sowie die
notwendigen Maÿnahmen zur Erhaltung der Ressource. Bei dieser Art von Metadaten
denkt man zuerst an alte Bücher oder Papyrusrollen, aber auch digitale Dateien können
beschädigt werden und benötigen diese Art von Metadaten, um ein langes Leben zu haben.
12.2.4. Technische Metadaten
Diese Informationen beschreiben, in welchen/m Format(en) die Metadaten vorliegen, welche
Hard- und Softwareanforderungen erfüllt sein müssen, um auf die Objekte zuzugreifen,
ob es sich um komprimierte Daten handelt oder wie die Metadaten der Objekte organisiert
sind. Ebenfalls in diese Kategorie fallen Sicherheits- und Authentikationsdaten wie
Passwörter oder Schlüssel.
123

KAPITEL 12. METADATEN
12.2.5. Nutzungsrelevante Metadaten
In dieser Katagorie nden sich alle Metadaten, die das Verhalten von Benutzern speichern.
Wie oft wurde ein Buch ausgeliehen? Wieviele Versionen eines Dokuments gibt es und
was sind die Unterschiede?
12.3. Bibliotheksmetadaten
Für Bibliotheken, egal ob konventionell oder digital, spielen Metadaten ein wichtige Rolle.
Angesichts groÿer Zahlen zu verwaltender Objekte fallen groÿe Datenmengen an, die trotzdem
noch ezient genutzt werden sollen. Ein hervorstechendes Merkmal von Metadaten
im Bibliotheksbereich ist ihre Komplexität. Bibliothekskataloge sollen angeben:
• ob die gesuchte Ausgabe eines Dokuments vorhanden ist
• welche Werke eines Autor vorhanden sind
• welche Ausgaben eines Dokuments vorhanden sind
• welche Werke zu einem bestimmten Thema vorhanden sind
[Bra99, Kap.10.7]
Dazu reicht es nicht, nur Titel und Autor eines Dokuments zu katalogisieren. Es müssen
Schlagwörter herausgeltert werden, die den Inhalt eines Werks repräsentieren, bei
mehrbändigen Werken müssen die Zusammenhänge der Einzeldokumente erhalten werden,
Bücher können mehrere Autoren haben, dazu noch einen Herausgeber und einen
Verleger uvam. Darüberhinaus ist es nötig zu speichern, wo das physische Objekt zu den
Metadaten zu nden ist, ob ausgeliehen, vorgemerkt, reparaturbedürftig, verschwunden
o.ä. ist.
Auch wenn man davon ausgehen kann, dass alle Bibliotheken die gleichen Daten benötigen,
darf man daraus nicht folgern, dass aus diesem Umstand nur ein einheitliches Format
entstanden wäre(s.12.8). Weltweit das meistgenutzte Format ist MARC, in Deutschland
wird überwiegend MAB2 genutzt.
Um Einheitlichkeit von Metadaten zu erreichen, ist allerdings nicht nur ein Formatstandard
nötig, sondern auch Übereinstimmung in der Anwendung dieses Standards. Dafür
muss ein kontrolliertes Vokabular benutzt werden, wie es in Deutschland z.B. durch die
Schlagwortnormdatei(SWD) vorgegeben wird.
Da sich die Projektgruppe mit der Realisierung eines Bibliotheksdienstes beschäftigt, wird
im folgenden im allgemeinen über Metadaten im Bibliotheksbereich ausgegangen.
12.4. Generierung von Metadaten
Wie kommt man an Metadaten? Während in konventionellen Bibliotheken Metadaten zu
den vorhandenen Dokumenten von den dort angestellten Menschen erstellt werden, ist
124

12.5. ZWECK VON METADATEN
dies für digitale Bibliotheken mit ihrer groÿen Menge an Materialien ein nicht gangbarer
Weg.
12.4.1. Experten
Der konventionelle Ansatz ist die Erstellung durch Menschen. Experten eines Gebietes
legen Metadaten zu Dokumenten/Objekten dieses Gebietes an. Das Ergebnis sind Metadaten
von hoher Qualität. Nachteile dieser Methode sind die hohen Kosten und die lange
Dauer der Erstellung. Menschen müssen die Texte lesen, in den richtigen Zusammenhang
bringen, katalogisieren, Schlüsselwörter heraussuchen usw. und wollen dafür bezahlt werden.
Ein anderer Weg ist, den Verfasser des jeweiligen Dokuments auch die Beschreibung
desselben anfertigen zu lassen.
12.4.2. Automatische Generierung
Mit zunehmender Menge der zu katalogisiernden Dokumente stöÿt diese Methode nanziell
und zeitlich an ihre Grenzen, also sucht man nach Wegen, Metadaten maschinell
erstellen zu können. Computer scannen Texte nach vordenierten Schlüsselwörtern und
katalogisieren die Dokumente dann entsprechend der gefundenen Kategorien. Diese Art
der Metadatengewinnung ist allerdings auf Textdokumente beschränkt, schon bei Bildern,
Noten oder Musikstücken stöÿt der Computer an seine Grenzen.
12.5. Zweck von Metadaten
Natürlich stellt sich die Frage, ob und wodurch der Aufwand und die Kosten zur Metadatenerstellung
gerechtfertigt sind. Unter der Voraussetzung, dass es sich um Metadaten
von hoher Qualität handelt, lassen sich diverse Vorteile ausmachen:
leichterer Zugri: Die Suche nach Dokumenten lässt dich durch Metadaten stark verbessern.
Es muss nicht der gesamte Inhalt untersucht werden, sondern nur die beschreibenden
Daten. Zudem erönen Metadaten die Möglichkeit, verschiedene Dokumententypen und
-sammlungen zu durchsuchen. Die Metadaten müssen dazu allerdings in einem standardisierten
Format vorliegen, damit eine solche Zusammenarbeit möglich ist.
Kontexterhaltung: Gerade bei archäologischen Objekten und Ausstellungsstücken ist
es wichtig, die Fundorte und Beziehungen untereinander zu dokumentieren. Da sich diese
Daten nicht aus den Objekten selbst gewinnen lassen, müssen sie in Metadaten gespeichert
werden. Aber auch bei Büchern, die Bände eines Gesamtwerkes sind, oder digitalen
Objekten, die mit anderen verknüpft sind, ist es wichtig, dies die Metadaten abzulegen,
damit der Zusammenhang nicht verloren geht.
Verbreitung: Digitale Dokumente sind wesentlich leichter zu erreichen als traditionelle
Medien. Bücher z.B. haben einen festen Standort in einer Bibliothek, gemalte Bilder hängen
in einem Museum. Von digitalen Objekten lassen sich beliebig viele Kopien erstellen,
die auf verschiedenen Servern liegen können, auf die weltweit zugegrien werden kann.
Damit erweitert sich der Nutzerkreis ernorm. Dadurch entstehen neue Ansprüche an die
125

KAPITEL 12. METADATEN
Objekte. In Metadaten können die Zugrie verschiedener Benutzer, die Art des Gebrauchs
eines Objekts u.ä. aufgezeichnet werden und so als Feedback dienen, um nutzerorientierte
Veränderungen zu ermöglichen.
Multi-Versioning: Objekte können in verschiedenen Versionen auftauchen, z.B. Bilder
in hoher und niedriger Auösung. In den Metadaten eines Objekts können die Anzahl der
Versionen und ihre Unterschiede festgehalten werden, genauso wie die Information, was
das Original und was die Kopien des Dokuments sind.
Rechteverwaltung: Metadaten ermöglichen die Speicherung von Zugangsrechten, die
für Objekte bestehen, z.B. ob ein Text zum privaten Gebrauch kostenlos vervielfältigt
werden darf oder was der Download eines Musikstücks kostet.
Erhaltung: Gerade bei digitalen Objekten ist es wichtig zu dokumentieren, unter welchen
Hard- und Softwarebedingungen auf sie zugegrien werden kann. Da sich Computersysteme
schnell verändern, muss nachzuvollziehen sein, unter welchen Bedingungen ein Objekt
erschaen wurde, um ihm diese Umgebung wieder herzustellen.
Eektivität: Metadaten können auch technischer Natur sein, z.B. Informationen über
Zugrie auf ein Repository, Benchmarks eines Rechners. All das lässt sich bei der Planung
neuer Systeme berücksichtigen und so die Eektivität steigern.
12.6. Speicherung
Damit Metadaten überhaupt einen Nutzen haben, müssen sie mit den beschriebenen Objekten
verknüpft werden. Dazu gibt es zwei Möglichkeiten: entweder die in die Metadaten
wird ein Identikationsmerkmal des zugrundeliegenden Objekts aufgenommen, dann
können Metadaten und Objekte getrennt abgespeichert werden(z.B. Kataloge), oder die
Metadaten werden in das Objekt eingebunden und mit ihm zusammen gespeichert(z.B.
Webseite)[Arm00].
Beide Verfahren haben Vor- und Nachteile. Werden Daten und Metadaten getrennt, kann
die Verküpfung zwischen beiden verloren gehen. Bei der gemeinsamen Speicherung wird
das Objekt verändert und vergröÿert. Nicht immer sind beide Wege gangbar. In konventionellen
Bibliotheken müssen Metadaten getrennt von ihren Objekten gespeichert werden,
um sie dem Benutzer gesammelt zur Verfügung stellen zu können.
12.7. Fragen/Probleme
So unbestritten der Nutzen von Metadaten ist, sie werfen auch Probleme auf. Die fangen
schon bei der Generierung an. Wieviele Metadaten braucht man? Wird der Metadatenkatalog
zu umfangreich, ist er unübersichtlich und behindert Suchende eher, als dass er
ihnen hilft. Wieviel Geld und Zeit will man aufwenden, um Metadaten zu sammeln? Welche
Qualität sollen diese Daten haben? Auf diese Fragen gibt es keine universell richtige
Antwort, sie müssen für jedes Projekt neu beantwortet werden.
Bibliotheksbestände ändern sich, Dokumente werden umgeschrieben, neu aufgelegt - die
Metadaten müssen aktuell gehalten werden. Es reicht nicht, Metadaten einmal zu erheben,
126

12.8. BEISPIELE
sie müssen gepegt werden. Das verursacht neue Kosten, je öfter aktualisiert wird, desto
mehr.
Die verschiedenen Formate und die fehlende Einheitlichkeit sind die gröÿten Probleme der
Metadatennutzung. Jedes Einsatzgebiet stellt andere Anforderungen an die Beschreibung
von Informationsobjekten. Es gibt sehr spezielle Formate, z.B. MeSH(Medical subject
headings) für Dokumente im medizinischen Bereich, bis hin zu allgemeinen Formaten wie
Dublin Core, das mit nur 15 Beschreibungselementen auf nahezu jedes Informationsobjekt
angewandt werden kann.
Für jedes Metadatenformat muss man unterscheiden zwischen Struktur- und Inhaltsregeln.
Nur weil Felder den gleichen Bezeichner haben, müssen sie nicht die gleiche Art
von Inhalt transportieren. Unter dem Namen Format lässt sich sowohl die Gröÿe eines
Objekt erfassen(z.B.DIN A4) wie auch dessen Datentyp(z.B. PDF). Es sind also nicht nur
einheitliche Strukturregeln nötig, um Austausch zu ermöglichen, sondern auch Einigung
über das Füllen dieser Struktur.
12.8. Beispiele
Zum Abschluss sollen einige Metadatenformate, die für Bibliotheken relevant sind, vorgestellt
werden. Dabei soll es mehr um deren Einsatzgebiete, Vor- und Nachteile gehen. Zu
Aufbau und Struktur der einzelnen Formate sei auf den Seminarbeitrag Metadatenstandards
verwiesen.
12.8.1. MARC
Das machine readable cataloging format(MARC) wurde Ende der 60er Jahre von der
Library of Congress(LoC) in den USA entwickelt. Aufgrund der Bedeutung der LoC in
der englisch sprachigen Welt wurde MARC schnell internationaler Standard. Anfangs
gab es verschiedene MARC-Varianten für Zeitschriften, Noten, Karten usw. Ende der
80er Jahre wurden sie zu dem Gesamtformat USMARC zusammengefasst. Unterschiede
zwischen nationalen USMARC-Varianten blieben jedoch bestehen. USMARC ist das am
weitesten verbreitete Format für Bibliotheksmetadaten[Bra99, Kap.10.1], was vor allem
auf das OCLC(Online Computer Library Center) zurückzuführen ist. Das OCLC erhebt
bibliographische Metadaten im MARC-Format, die von vielen Bibliotheken genutzt werden(s.http://www.oclc.org).
12.8.2. MAB
MAB steht für Maschinelles Austauschformat für Bibliotheken. MAB entstand in den
70er Jahren, seit 1995 ist MAB2 der Standard, der auch Online-Einsätze ermöglicht.
MAB besteht auf fünf einzelnen Formaten, die alle eine einheitlich Feldstruktur besitzen:
• MAB-TITEL für bibliographische Daten
• MAB-PND für Personennamen
127

KAPITEL 12. METADATEN
• MAB-GKD für Körperschaftsnamen
• MAB-SWD für Schlagwörter
• MAB-LOKAL für Lokaldaten
[diea] Die Felder werden durch dreistellige Nummern identiziert, die die Bedeutung des
nachfolgenden Datums festlegen. MAB hat vor allem Schwächen in der Wiederholung von
Feldern(z.B. bei mehreren Autoren), die die Katalogeinträge unnötig aufblähen, und hat
eine unübersichtliche Einteilung des Titelfelds in verschiedene Untersätze. Ein weiteres
Problem sind redundant gespeicherte Schlagwortketten, was bei den enormen Datenmengen
unbedingt vermieden werden sollte[Bra99, Kap.10.2.].
12.8.3. Dublin Core
Das Dublin-Core-Format verfolgt einen ganz anderen Ansatz und ist auch nicht ursprünglich
für bibliothekarische Zwecke entwickelt worden. Es soll Katalogisierung vereinfachen
und in möglichst vielen Fällen anwendbar sein, um so Kooperation unterschiedlicher Gebiete
zu fördern.
Der Dublin Core umfasst 15 Elemente, die alle optional sind und beliebig oft wiederholt
werden können:
• Title - Titel der beschriebenen Ressource
• Creator - Hauptverantwortlicher für den Inhalt
• Subject - Schlüsselwort für den Inhalt
• Description - Beschreibung des Inhalts
• Publisher - Verantwortlicher für die Veröentlichung der Ressource
• Contributor - Beteiligter am Entstehen der Ressource
• Date - Entstehungsdatum
• Type - Art der Ressource
• Format - Format der Ressource
• Identier - Einzigartiger Bezeichner zur Identizierung
• Source - Verweis auf andere Ressource die der beschriebenen zugrunde liegt
• Language - Sprache des Inhalts
• Relation - Beziehung zu einer anderen Ressource
• Coverage - zeitliche und räumliche Eigenschaften der Ressource
• Rights - Informationen zum Rechtemanagement
128

12.9. FAZIT
[Ini]
Mit diesen Elementen lassen sich Ressourcen einfach beschreiben. Es bleibt allerdings die
Frage, ob sie für alle Anwendungszwecke ausreichen und präzise genug sind[Arm99].
12.8.4. MABxml
XML ist als Austauschformat weit verbreitet. Es bietet vielfältige Möglichkeiten zur Weiterverarbeitung,
z.B. XSLT. Um die Vorteile von XML auch mit MAB2-Datensätzen
nutzen zu können, wurde MABxml entwickelt. Es soll exemplarisch für Mapping zwischen
den verschiedenen Formaten vorgestellt werden.
MABxml setzt die MAB2-Tags in XML-Tags um. Für jeden Katalogeintrag wird ein
XML-Element datensatz erstellt, dessen Unterelemente alle MAB-Attribute repräsentieren.
Ein Beispiel für einen MABxml-Datensatz ndet sich hier: http://www.ddb.de/
standardisierung/formate/mabxml_beispiel_ebene1.xml Für spezielle MAB2-Trennund
Steuerzeichen(z.B. Teilfeldtrennzeichen, Nicht-Sortierzeichen) gibt es eigene Tags,
sämtliche Inhaltsdaten sind in feld-Elementen abgelegt, die als Nummer das entsprechende
MAB2-Tag übernimmt[dieb]. Damit ist MABxml so zu lesen wie MAB. Es ndet
also kein inhaltliches Mapping statt, sondern nur ein syntaktisches.
12.9. Fazit
Metadaten, besonders im Bibliotheksbereich, können umfangreich und komplex sein. Um
damit trotzdem die Vorteile des einfacheren Zugris auf und der leichteren Verwaltung
von Informationsobjekten nutzen zu können, müssen Standards geschaen und eingehalten
werden. Dabei ist der Grundsatz so einfach wie möglich, aber so präzise wie nötig
anzuwenden. Je schlichter die Metadatenkategorien, desto aussageloser werden sie. Je konkreter
sie sind, desto weniger allgemein werden sie. Bei der Entwicklung von Standards
sollte die Frage, wieviele Metadaten überhaupt sinnvoll sind, stets im Blick behalten werden.
Ein gemeinsames Format für alle erdenklichen Metadaten, das allen Anwendungen
und Bedürfnissen Rechnung trägt, wird es kaum geben und ist auch nicht unbedingt
sinnvoll. Universelle Vergleichbarkeit von Daten bringt nicht zwangsläug brauchbare Ergebnisse
- wo sollte der Nutzen einer Verknüpfung medizinischer Fachblätter mit der
IMDB(http://www.imdb.com) sein? Doch in vielen Fällen ist Austausch erwünscht und
dann sollte er auch möglich gemacht werden.
129

13. Metadatenstandards
13.1. Einleitung
Metadaten über Dokumente sind in der automatisierten Verarbeitung unerlässlich. Viele
Dokumentformen sind primär auf die Betrachtung durch Menschen ausgelegt anstatt auf
das Parsen und Verarbeiten durch Maschinen (z.B. ps, pdf, jpg). Um solche Dokumente zu
verwalten, katalogisieren und auszutauschen benötigt man ein externes Metadatenformat
welches Informationen wie Autor, Copyright, Datum u.Ä. festhält. (Siehe hierzu auch: 12)
Zu Anfangszeiten der automatischen Verarbeitung von Dokumenten haben viele Institutionen
und Organisationen mit dieser Katalogisierung voneinander isoliert begonnen.
Dies führte dazu, dass jeder Katalog seine Metadaten in einem unterschiedlichen Format
verwaltete, oft inkompatibel zu allen anderen.
Mit dem Auftreten des Internet entstand nun der Wusch, diese verteilten Kataloge zu
vereinen, auszutauschen oder abzugleichen, was aufgrund der unterschiedlichen Metadaten
zu schwerwiegenden Problemen führte.
Aus diesem Grund engagierten sich diverse Institutionen wie z.B. die US-Amerikanische
LOC 1 oder das W3C 2 um anerkannte Standards für diese Metadaten zu schaen. Das
Ergebnis dieses Engagements ist eine Reihe von Standards angepasst an unterschiedliche
Zwecke. Einige dieser Standards werden hier nun im einzelnen betrachtet und erläutert.
13.2. Metadatenstandards
13.2.1. Dublin Core
Dublin Core (DC) ist ein weit verbreiteter Standard zur Beschreibung Digitaler Objekte
der von der DCMI 3 weiterentwickelt wird. DC ist kein bibliothekarisches Format sondern
versteht sich selbst eher als kleinster gemeinsamer Nenner im Bezug auf Metadaten. Es
werden hierbei nur grundlegende Informationen zu einem Objekt gespeichert die allerdings
dennoch eine gute allgemeingültige Beschreibung liefern.
DC Beschreibungen werden in XML ausgedrückt und sind somit sowohl durch Menschen
als auch durch Maschinen leicht zu verstehen und weiterzuverarbeiten. Weiterhin besteht
DC nur aus einigen wenigen Elementen, was die Arbeit mit diesem Format weiter vereinfacht.
1
Library of Congress - http://www.loc.gov/
2
World Wide Web Consotium - http://www.w3c.org/
3
Dublin Core Metadata Initiative - http://www.dublincore.org/
130

13.2. METADATENSTANDARDS
Zur Beschreibung von Objekten stehen mit DC folgende Elemente zur Verfügung:
• 15 core Elemente:
Title: Name der Ressource
Creator: die für den Inhalt verantwortliche Person oder Organisation
Subject: Thema des Inhalts
Description: Zusammenfassung des Inhalts
Publisher: Organisation oder Person die den Inhalt zugänglich gemacht hat
Contributor: Organisation oder Person die eine Beitrag zum Inhalt der Ressource
geleistet hat
Date: das Erstellungsdatum
Type: Art der Ressource
Format: digitale oder physikalische Repräsentation der Ressource
Identier: eindeutige Referenz der Ressource (z.B. ISBN Nummer, URL)
Source: Quelle der Ressource
Language: Sprache des Inhalts
Relation: Referenz zu anderen, verwandten Ressourcen
Coverage: Bereich, den der Inhalt abdeckt (Zeitraum, geographisches Gebiet...)
Rights: Information zu den mit der Ressource verknüpften Rechten (z.B. Copyright
• 3 weitere qualied Elemente:
Audience, Provenance, RightsHolder
• Pro Element auch Subelemente (qualier) möglich:
z.B.: created, valid, issued, modied für das date Element
Diese Elemente dürfen innerhalb eines DC Datensatzes mehrfach wiederholt werden. Ein
Beispiel für einen DC Datensatz ndet sich im Kapitel 13.2.6.
13.2.2. MARC
MARC steht für MAchine Readable Caloging und ist ein Metadatenstandard, der von
der LOC entwickelt wurde um es Computern zu ermöglichen bibliograsche Informationen
auszutauschen, zu nutzen und zu interpretieren [LOCa]. Dabei sind aus dem inzwischen
30 Jahre alten MARC Standard mehrere Nachfolger und Abwandlungen entstanden, so
dass es heute eine ganze Reihe leicht unterschiedlicher MARC Versionen gibt, die sich
allerdings bemühen weitgehen zueinander kompatibel zu bleiben.
131

KAPITEL 13. METADATENSTANDARDS
Einige bekannte MARC Standards und deren Verwendung:
• USMARC: nationaler MARC Standard für die USA
• CAN/MARC: nationaler MARC Standard für Canada
• MARC 21: Harmonisation von USMARC und CAN/MARC
• INTERMARC: MARC benutzt von der Bibliotheque nationale de France
• UNIMARC: (IFLA 1977), ozielles MARC in Frankreich
IFLA = International Federation of Library Associations
• CMARC: nationaler MARC Std. der Volksrepublik China, basiert auf UNIMARC
• DANMARC: nationaler MARC Std. in Dänemark, basiert auf MARC21
• NORMARC: nationaler MARC Std. in Norwegen, basiert auf MARC21
• BIBSYS-MARC: alle Norwegischen Uni-Bibliotheken, US National Library, alle US-College
Bibliotheken, einige Forschungseinrichtungen
Die Standards USMARC und CAN/MARC sind dabei in den 80er Jahren aus dem ursprünglichen
MARC Standard hervorgegangen und wurden Ende der 90er zu MARC 21
harmonisiert. MARC 21 ist wiederum die Basis für viele weitere nationale Varianten.
Der MARC Standard besteht aus mehreren nach Anwendungsgebiet getrennten Bereichen.
Wichtig sind hier vor allem MARC 21 Format for Bibliographic Data und MARC
21 Format for Authority Data. Ersterer ist dabei zuständig für konkrete Kataloge (bestand
einer Bibliothek) während der zweite Bereich konstante Daten wie Autorennamen,
Schlagwörter usw. enthält. Dieser Bereich steht üblicherweise unter authoroty Control,
das heiÿt, es gibt eine festgelegte Instanz, die berechtigt ist, diese Daten zu ändern und
zu erweitern, während andere die Daten nur nutzen. (In den USA ist diese Instanz z.B.
die LOC.) Dieses Verfahren hat den Vorteil, dass Autoreninformationen usw. innerhalb
der ganzen Nutzergemeinschaft konsistent sind und Fehler vermieden werden können.
Zudem gibt es noch Regelungen für die Änderungen an MARC selbst. Sofern eine Institution
eine Änderung oder Erweiterung des MARC-Formates wünscht, muss sie sich an
das MARC Standards Comitee wenden, welches dann über die Eingabe berät und evtl.
ein Update des MARC-Standards veranlasst. Dieser Prozess nimmt oft eine längere Zeit
in Anspruch.
Als bibliographisches Format hat MARC einige hochgesteckte Anforderungen zu erfüllen.
Es müssen alle Informationen die zuvor auf einer üblichen Bibliotheks-Registerkarte
Verwendung gefunden haben auch in MARC ausdrückbar sein, und dies in einer maschinenverarbeitbaren
Form die, (man bedenke hier, dass das Format in den 60er Jahre
geschaen wurde) auÿerdem noch möglichst Speicherezienz sein muss. MARC löst dies
über Kombinationen von Tags, Indikatoren und Subelds die durch eine Reihe von
Zahlen und Sonderzeichen ausgezeichnet werden.
Ein Beispiel für eine Publikation:
132

13.2. METADATENSTANDARDS
Listing 13.1: Beispiel: Publikation
place of publication: New York
name of publisher:
Lothrop, Lee & Shepard Books
date of publication: 1987
Der entsprechende MARC-Record sähe dann wie folgt aus:
260 ## $a New York
$b Lothrop, Lee & Shepard Books
$c 1987
Listing 13.2: Beispiel: MARC
Wobei 260 das entsprechende Tag für eine Publikation wäre, ## ein Platzhalter, da es
keine Indikatoren für diesen Fall gibt und $a, $b, $c die dazugehörigen Subelds. So
können Speicherezient auch mehrwertige Daten gespeichert werden und sind von einem
Katalogsystem leicht zu verstehen. Der Nachteil ist, dass man als Mensch die Daten
ohne Dokumentation und tiefgehendes bibliothekarisches Wissen nicht ohne weites Nutzen
kann. Ein Versuch diese Situation zu verbessern ist z.B. MODS (13.2.3).
13.2.3. MARCXML und MODS
MARCXML 4 und MODS 5 sind Transformationen von MARC auf XML. Da XML sich als
weitgehend als Standard für die Übertragung und Speicherung von hierarchischen digitalen
Daten durchgesetzt hat, wurden auch für das betagte MARC Format entsprechende
Transformationen entwickelt. Hier orientiert sich MARCXML sehr nah am originalen
MARC während MODS eher ein echtes XML Format ist. Dies lässt sich am besten an
einem Beispiel verdeutlichen.
Listing 13.3: Beispiel: MARCXML
01142cam 2200301 a 4500
92005291
DLC
19930521155141.9
92005291
0152038655 :
$15.95
...
4 http://www.loc.gov/standards/marcxml/
5
Metadata Object Description Schema - http://www.loc.gov/standards/mods/
133

KAPITEL 13. METADATENSTANDARDS

13.2. METADATENSTANDARDS
Hier ist z. B. ein MARC-Record in einen EAD-Record eingebettet.
Auch wenn EAD mit seiner Struktur sehr exibel ist, wurde es trotzdem primär zum
Austausch von Bibliotheksinformationen geschaen. Also zur Beschreibung von realen
Büchern die in einer Bibliothek in einem Regal physisch vorhanden sind. Wenn es um
Metadaten über digitale oder digitalisierte Informationen geht, eignet sich das METS
Format im Allgemeinen eher.
13.2.5. METS
METS: Metadata Encoding and Transmission Standard
The METS schema is a standard for encoding descriptive, administrative,
and structural metadata regarding objects within a digital library, expressed
using the XML schema language of the World Wide Web Consortium. The
standard is maintained in the Network Development and MARC Standards
Oce of the Library of Congress, and is being developed as an initiative of
the Digital Library Federation. [LOCb]
METS wurde entwickelt, um die erweiterten Ansprüche an Metadaten zu erfüllen, die digitale
Dokumente stellen. Digitale Dokumente bestehen nicht immer nur aus einer einzelnen
Datei. Um aber komplexe Strukturen zusammenzuhalten sind die bestehenden Strukturen
nicht geeignet, da sie immer von einem Dokument als einzelne Entität ausgehen.
Auÿerdem bildet METS weitere Metadaten ab, die die Digitalisierung von Dokumenten
betreen, z. B.:
Originalquelle: Eine Referenz auf das zugrundeliegende Dokument der digitalen Fassung
Verlässlichkeit: Ist die (online verfügbare) Quelle aktuell, zuverlässig,. . .
Copyright: Das Copyright für Onlinedokumente hat oft andere Anforderungen
. . .
Ein Beispieldokument im METS Format ndet sich im Anhang 13.4.1. Wie man dort
sieht, besteht ein METS Dokument aus mehreren Abschnitten. Wichtige Abschnitte sind
z. B.:
METS Header: Metadaten, die das METS Dokument an sich beschreiben, wie z.B. creator,
editor, usw.
Descriptive Metadata: Links zu beschreibenden Metadaten innerhalb und/oder auÿerhalb
des METS Dokumentes. Beispielsweise ein MARC record oder ein EAD Quellverzeichnis
auf einem WWW-Server. (Multiple Instanzen möglich).
Administrative Metadata: Informationen darüber, wie die Dateien erstellt wurden, Urheberrechte,
Angaben zur Originalquelle des digitalen Dokumentes, usw. Sowohl
interne als auch externe Daten sind möglich.
135

KAPITEL 13. METADATENSTANDARDS
File Section: Liste der Dateien die das digitale Objekt ausmachen. Elemente
können über gruppiert werden um die Struktur abzubilden.
Structural Map: Das Herz des METS Dokumentes. Angaben über die hierarchische
Struktur und Links zu Content und weiteren Metadaten.
Structural Links: Die Strukturellen Links erlauben es Autoren von METS Dokumenten,
Hyperlinks zwischen Strukturelementen zu denieren.
Behavior: Die behavior section erlaubt es, Content im METS Dokument mit ausführbaren
Verhalten zu verknüpfen. (Quasi eine Art Script-Engine).
METS ermöglicht somit über sein exible Baustein-artige Struktur den Austausch fast
beliebiger Metadatensätze mit dem Zusatz, dass Informationen über die Digitalisierung
sowie über den Zusammenhang mehrerer Dateien die ein einzelnes Dokument formen
integriert werden können.
13.2.6. OAI
OAI sowie das OAI-PMH (Protocol for Metadata Harvesting) der OAI 6 ist kein Metadatenstandard
im engeren Sinne sondern ein Protokoll zum Austausch von Metadaten
über digitale Dokumente. OAI wurde entwickelt, um Autoren eine möglichst reibungslose
Zusammenarbeit in der Veröentlichung und Verbreitung von Information zu ermöglichen.
OAI durchforstet Informationsdepots unter Verwendung von gemeinsamen Metadatenstandards.
Wenn ein solcher Informationsspeicher diesem gemeinsamen Standard
entspricht, kann er Teil einer gröÿeren Community werden und somit den Wert seines
eigenen Depots und den der Gemeinschaft anheben. Derzeit beteiligen sich zum Beispiel
die Digital Library Federation, CrossRef und OCLC 7 rege an diesem Projekt.
Um dies zu ermöglichen wird die Arbeit auf 2 Bereiche aufgeteilt:
• Data Providers: Diese Teilnehmer machen ihre Daten über das OAI Protokoll erreichbar.
• Service Providers: Dies sind jene Teilnehmer, welche die Metadaten von den verschiedenen
Servern einsammeln und zur Verfügung stellen.
OAI selbst ist hierbei nur das Austauschformat und beinhaltet keine Metadaten in Bezug
auf Dokumente, dafür kann ein OAI Record mehrere Subelemente enthalten
die jeweils einen Metadatenblock in einem frei denierbarem Format zu dem referenziertem
Dokument enthalten. Hierbei ist das Vorhandensein des Formates oai_dc (Dublin
Core, siehe Kap. 13.2.1 ) zwingend erforderlich, um den bereits erwähnten kleinsten gemeinsamen
Nenner zu erfüllen, der einen Austausch der Metadaten zu jedem Zeitpunkt
6
Open Archive Initiative - http://www.openarchives.org
7
Online Computer Library Center http://www.oclc.org
136

13.2. METADATENSTANDARDS
gewährleistet. Anfragen an OAI-Repositories (Data-Provider) werden über das etablierte
HTTP-Protokoll durchgeführt. Dabei muss der Provider sowohl GET als auch POST
Anfragen unterstützen.
Eine (beispielhafte) OAI-Anfrage könnte z.B. so aussehen:
Listing 13.6: Beispiel: OAI Anfrage
http://cs1.ist.psu.edu/cgi-bin/oai.cgi?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai%3
ACiteSeerPSU%3A2412
(Eine Anfrage nach einem einzelnen Record mit der ID oai:CiteSeerPSU:2412 und Metadaten
im DC Format)
Die entsprechende Antwort:
Listing 13.7: Beispiel: OAI Antwort
2006-04-17T00:18:39Z
http://cs1.ist.psu.
edu/cgi-bin/oai.cgi
oai:CiteSeerPSU:2412
1999-02-12
CiteSeerPSUset
Dynamic Staffing In A Telephone Call Center Aiming To Immediately Answer All Calls
Ward Whitt
Ward Whitt Dynamic Staffing In A Telephone Call Center Aiming To Immediately Answer All
Calls
This paper proposes modeling and analysis methods to facilitate dynamic staffing in
a telephone
call center...
The Pennsylvania State University CiteSeer Archives
unknown
1999-02-12
ps
http://citeseer.ist.psu.edu/2412.html
http://www.research.att.com/library/trs/./TRs/98/98.34/98.34.1.body.ps
en
oai:CiteSeerPSU:405726
oai:CiteSeerPSU:403464
unrestricted
Hier ist sehr gut zu erkennen, dass der OAI-Record an sich ausschlieÿlich Daten zur
137

KAPITEL 13. METADATENSTANDARDS
Speicherung im Online-Repository enthält, während der DC-Datensatz innerhalb von
liegt.
13.3. Fazit
Die heutige Informationsut ist ohne strukturierende Metadaten über die verfügbaren
Dokumente kaum zu bewältigen. Doch auch Anhäufungen von Metadaten an sich schaffen
hier nicht ohne weites Abhilfe. Diese Metadaten müssen untereinander vergleichbar,
kombinierbar und vor allem zwischen verschiedenen Katalogen au tauschbar sein. Um
Dies zu ermöglichen müssen Metadaten in einem standardisiertem Format vorliegen. Im
laufe der Zeit sind so einige Standards geschaen worden, die, durch Gremien kontrolliert,
eine Grundlage für die interoperable Speicherung von Metadaten bieten. Selbstverständlich
ist es nicht möglich, alle Anforderungen an Metadaten in einem einzelnen Standard
unterzubringen, dennoch decken die bestehenden Initiativen gröÿtmögliche Bereiche im
bibliothekarischen Bereich (MARC, MODS) oder im Datenaustausch (METS, EAD, OAI)
ab, so dass einige wenige gut durchdachte Formate für viele Anforderungen ausreichen.
Mit dem Universalformat Dublin Core gibt es sogar eine Grundstruktur, die zumindest
die wichtigsten Informationen zu (fast) jedem digital verfügbaren Objekt vorhalten kann.
Diese Arbeit von Initiativen wie den Standards-Comitees des LOC oder der DMCI macht
es heute möglich, riesige Bestände an (wissenschaftlich relevanten) Informationen Weltweit
zu identizieren, zu nutzen und auszuwerten.
13.4. Anhang
13.4.1. METS Beispiel
Listing 13.8: Beispiel: METS Record
Since the intended use of these file is internal (i.e. not for
distribution to other digital libraries) local numbers are used
for xlink:href values which correspond to the local digital
repository's id numbers. These numbers would be translated into
proper URIs for distribution beyond Harvard.
138

13.4. ANHANG
Reports of the president and treasurer for..., 1912-1914. [Title page]
Radcliffe College
139

KAPITEL 13. METADATENSTANDARDS
140

Teil II.
Ergebnisdokumente der
Softwareentwicklung
141

14. Bewertung von bestehenden
Bibliotheksdiensten
Die Projektgruppe hat einen Kriterienkatalog erstellt, mit dem die Internetangebote von
vier Bibliotheken bewertet wurden:
1. Bibliotheks- und Informationssystem der Universität Oldenburg BIS
(http://www.bis.uni-oldenburg.de)
2. Niedersächsische Staats- und Universitätsbibliothek Göttingen SUB
(http://www.sub.uni-goettingen.de)
3. Gemeinsamer Bibliotheksverbund der Länder Bremen, Hamburg, Mecklenburg-Vorpommern,
Niedersachsen, Sachsen-Anhalt, Schleswig-Holstein, Thüringen und der
Stiftung Preussischer Kulturbesitz GBV
(http://www.gbv.de)
4. Technische Informationsbibliothek / Universitätsbibliothek Hannover TIB
(http://www.tib.uni-hannover.de)
Der Kriterienkatalog ist in die fünf Teilbereiche Standardfunktionalität, Strukturdarstellung,
Suchfunktion, Suchmaske und Ergebnispräsentation unterteilt. Zu jedem Teilbereich
sind Kriterien deniert. Jedes Kriterium wird mit einem Wert von 1-5 bewertet. Auÿerdem
gibt es zu jedem Kriterium eine Gewichtung von 1-5 (1 ist jeweils der schlechteste
und 5 der beste Wert). Die Gewichtung gibt an, welchen Stellenwert die Projektgruppe
einer bestimmten Funktion in einem Bibliotheksdienst einräumt.
Die Bewertung wurde von den 12 PG-Mitgliedern anhand des Kriterienkataloges vorgenommen.
Die hier präsentierten Ergebnisse sind die Durchschnittswerte aus allen Einzelergebnissen.
Die Gewichtung wurde bei dieser Berechnung nicht berücksichtigt. Der
Durchschnittswert ist dann die Summe der Einzelergebnisse geteilt durch 12.
In diesem Dokument werden die einzelnen Teilbereiche mit den entsprechenden Kriterien
vorgestellt und das Ergebnis der Bewertung analysiert. Ziel der Analyse ist es Stärken und
Schwächen des BIS zu ermitteln und dadurch Verbesserungsmöglichkeiten zu nden. Da
sich die drei anderen Bibliotheksdienste in vielen Bereichen ähneln liegen die Bewertungen
oft sehr dicht zusammen.
143

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
14.1. Standardfunktionalität
Die Standardfunktionalität beschreibt die Basisfunktionen, die jeder Bibliotheksdienst
anbieten sollte. Das lässt sich auch an der Gewichtung ablesen. Nur die Ausleihe aus digitalen
Bibliotheken hat nicht die höchste Gewichtung, liegt aber mit dem Wert 4 immer
noch im oberen Bereich. Die Ergebnisse liegen alle zwischen 1,67 und 3,67. Damit ist
die Umsetzung der Basisfunktionen in den untersuchten Bibliotheken bestenfalls befriedigend/gut.
Das BIS erzielt bei Verlängerung, Vorbestellung und Benutzerkonto das beste
Ergebnis. Bei der Suche ähneln sich die Bewertungen, alle Durchschnittswerte betragen
ca. 3. Dezite hat das BIS allerdings in der Bereichen Ausleihe aus digitalen Bibliotheken
und Online-Hilfe.
14.1.1. Ausleihe
Beschreibung:
Diese Funktion ermöglicht es dem Benutzer elektronische Medien (z.B. E-Books, Filme,
Tonträger) online auszuleihen.
Ergebnis:
Das BIS erzielt bei diesem Kriterium mit 1,67 das schlechteste Ergebnis. Die anderen
Bibl. sind aber auch bestenfalls befriedigend (2,33-2,75).
Analyse:
Beim BIS ist die Ausleihe von elektronischen Medien nicht integriert, sondern es wird
lediglich mit externen Anbietern verlinkt.
14.1.2. Verlängerung
Beschreibung:
Der Benutzer kann mit dieser Funktion ausgeliehene Medien verlängern. Dazu gehört
natürlich auch das Rückgängig machen von fälschlicherweise gemachten Verlängerungen.
Ergebnis:
Bei der Verlängerung erzielt das BIS mit 3,08 ein gutes Ergebnis. Die restlichen Bibl.
sind wesentlich schlechter mit ausreichend bewertet worden. Die Bewertung der Verlängerungsfunktion
war aber als nicht registrierter Benutzer auch schwierig.
Analyse:
Die Verlängerungsfunktion im BIS ist gut umgesetzt. Der Benutzer meldet sich an seinem
Benutzerkonto an und kann dann die Ausleihfristen verlängern. Leider kann man aber keine
einzelnen Titel auswählen. Die einzige Möglichkeit zur Dierenzierung besteht darin
alle Titel ohne Fernleihen, alle Titel mit Fernleihen oder nur die Fernleihen zu verlängern.
Komfortabel ist dagegen die Option sich nach erfolgter Fristverlängerung eine Übersicht
per E-Mail schicken zu lassen. Die Verlängerungsfunktion im BIS ist gut umgesetzt. Der
Benutzer meldet sich an seinem Benutzerkonto an und kann dann die Ausleihfristen verlängern.
Leider kann man aber keine einzelnen Titel auswählen. Die einzige Möglichkeit
zur Dierenzierung besteht darin alle Titel ohne Fernleihen, alle Titel mit Fernleihen oder
144

14.1. STANDARDFUNKTIONALITÄT
nur die Fernleihen zu verlängern. Komfortabel ist dagegen die Option sich nach erfolgter
Fristverlängerung eine Übersicht per E-Mail schicken zu lassen.
14.1.3. Vorbestellung
Beschreibung:
Mit der Vorbestellung können ausgeliehene Werke vorbestellt werden. Es sollte auch möglich
sein eine Vorbestellung wieder rückgängig zu machen.
Ergebnis:
Die Vorbestellung ist beim BIS am besten gelöst (3,67). Man kann ausgeliehene Werke
vormerken, eine Übersicht vorgemerkter Werke einsehen und Vormerkungen löschen. Der
GBV erzielt mit 2,83 den schlechtesten Wert. SUB (3,17) und TIB (3,42) sind auch befriedigend/gut.
Auch bei dieser Funktion war die Bewertung ohne Benutzerausweis schwierig.
Analyse:
Wenn ein Werk ausgeliehen ist kann sich der Benutzer über einen Link den Dialog für die
Vorbestellung anzeigen lassen. Dort erfährt er den Standort, wie lange das Werk ausgeliehen
ist und wieviele Vormerkungen vorliegen. Für die Vormerkung sind Benutzernummer
und Passwort nötig. Wenn der Benutzer in seinem Benutzerkonto eine E-Mail Adresse eingetragen
hat, wird er beim Vorliegen des Werkes automatisch benachrichtigt. Es besteht
auch die Option für eine kostenpichtige schriftliche Benachrichtigung.
14.1.4. Suche
Beschreibung:
Die Suche ist wohl die elementarste Funktion, die ein Benutzer von einem Bibliotheksdienst
erwartet. Die einzelnen Suchfunktionen und die Suchmaske werden deshalb weiter
unten noch detaillierter behandelt. Hier ist mit Suche einfach nur das Angebot der Suchfunktion
gemeint.
Ergebnis:
Alle untersuchten Bibl. haben ein Ergebnis zwischen 3 und 3,42 erzielt und verfügen damit
über eine befriedigende bis gute Suchfunktion. Am schlechtesten hat das BIS mit einer 3
abgeschnitten. Die anderen drei Kandidaten liegen um 3,4.
Analyse:
Das BIS verfügt über eine einfache und eine erweiterte Suche. Es besteht an einigen
Punkten die Möglichkeit die Suchfunktion zu verbessern. Die einzelnen Punkte werden
im weiteren Verlauf detailliert behandelt.
14.1.5. Online-Hilfe
Beschreibung:
Jeder Bibliotheksdienst sollte über eine Online-Hilfe verfügen, die es einem unerfahrenen
Benutzer ermöglicht alle angebotenen Funktionen zu nden und zu nutzen. Unter Hilfe
sind Hilfeseiten, Assistenten/Wizards und Tool-Tipps zu verstehen. Eine gute Online-Hilfe
145

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
sollte auch nicht nur in deutscher Sprache sondern zumindest auch in englisch verfügbar
sein.
Ergebnis:
Die schlechteste Online-Hilfe ist im BIS zu nden. Die Note 2,33 ist gerade so ausreichend.
Alle anderen Hilfefunktionen liegen ungefähr bei 3. Die beste Online-Hilfe hat das SUB
(3,33).
Analyse:
Im BIS sucht man das Wort Hilfe vergeblich, geschweige denn mehrsprachige Hilfetexte.
Die Hilfefunktion ist einer der Hauptschwachpunkte des BIS. Es besteht allerdings die
Möglichkeit Fragen an einen Mitarbeiter des BIS zu stellen (BIS.LiveInfo). Leider ist
dieser Service allerdings nur Montags - Freitags zwischen 10 - 16 Uhr zu benutzen. Aber
dann bestimmt mehrsprachig !?!
14.1.6. Benutzerkonto
Beschreibung:
In einem Benutzerkonto sind persönliche Daten des Benutzers hinterlegt. Unter persönlichen
Daten sind zum einen Anschrift und E-Mail zu verstehen, zum anderen gehören
dazu auch die aktuellen Ausleihen, Vormerkungen, Verlängerungen und Fernleihen. Auch
ein Gebührenkonto/Bezahlsystem mit einer Übersicht der Gebühren für Mahnungen oder
Fernleihen könnte unter einem Benutzerkonto zu nden sein. Der Benutzer sollte seine
persönlichen Daten selbst pegen können (z.B. bei einem Adresswechsel). In einem Benutzerkonto
können auch Benutzerprole gespeichert sein. Der Benutzer kann sich so ein
Prol anlegen, das später bei anderen Funktionen benutzt wird (z.B. bekommt die Pro-
lgruppe Informatik bei einer Suche auch nur Ergebnisse aus diesem Bereich angezeigt).
Ergebnis:
Keine der Bibl. hat das Benutzerkonto besonders gut umgesetzt. Die Ergebnisse sind bestenfalls
befriedigend. Das BIS erzielt mit 2,92 das beste Ergebnis. Die anderen Bibl. sind
nur leicht schlechter. Am schlechtesten schneidet der GBV ab (2,33). Ohne eingetragener
Benutzer der jeweiligen Bibliothek zu sein, war eine Bewertung allerdings schwierig.
Analyse:
Das Benutzerkonto ist zuerst einmal schwierig zu nden. Der Link trägt den nicht ganz
eindeutigen Namen Kontoabfrage. Sehr gut ist die Möglichkeit der verschlüsselten Verbindung
(SSL). Das Benutzerkonto ist unübersichtlich gestaltet. Im ersten Dialog muss
der Benutzer auswählen, welche Funktion er nutzen will. Wieso kann hier nicht schon eine
Übersicht der ausgeliehenen und vorbestellten Werke stehen? Als Funktionen stellt das
Benutzerkonto die Kontoanzeige und Fristverlängerung (getrennt nach Uni- und Landes-
Bibliothek), die Adressänderung und eine Magazinbestellung in der Landesbibliothek zur
Verfügung. Der Benutzer kann auÿerdem seine E-Mail Adresse editieren und aktivieren/-
deaktivieren. Benutzerprole werden nicht verwendet.
146

14.2. STRUKTURDARSTELLUNG
14.2. Strukturdarstellung
Zur Strukturdarstellung gehören 4 Kriterien. Die Mahnungsverwaltung/Benachrichtigungsfunktion
ist mit einer 4 gewichtet. Für alle anderen Kriterien wurde als Gewichtung 5
festgelegt. Die Bewertungen liegen zwischen 1,75 und 3,58. Damit gibt es auch bei der
Strukturdarstellung keine sehr guten Ergebnisse. Das BIS belegt jeweils zweimal den besten
(Mahnungsverwaltung, Trennung von eigenen und fremden Inhalten) und zweimal
den schlechtesten Rang (Fernleihe, Ergonomie).
14.2.1. Mahnungsverwaltung / Benachrichtigungsfunktion
Beschreibung:
Mit diesem Kriterium ist eine Funktion zur Benachrichtigung des Benutzers gemeint, wenn
dieser Gefahr läuft einen Ausleihzeitraum zu überschreiten bzw. schon überschritten hat.
Diese Benachrichtigung kann entweder über E-Mail oder mit der Post erfolgen.
Ergebnis:
Das BIS erzielt hier mit 2,17 den besten Wert. Die anderen Bibl. sind leicht schlechter. Am
Schlechtesten haben GBV und TIB abgeschnitten (1,75). Die Benachrichtigungsfunktion
ist damit bei allen Kandidaten nicht besser als ausreichend.
Analyse:
Wenn der Benutzer in seinem Benutzerkonto eine E-Mail Adresse eingetragen hat, bekommt
er im Fall der Überschreitung der Leihfrist eine Nachricht. Wenn im System keine
E-Mail Adresse gespeichert ist, wird der Benutzer schriftlich benachrichtigt.
14.2.2. Fernleihe (Vorbereitung)
Beschreibung:
Bei einer Fernleihe will der Benutzer ein Werk ausleihen, das nicht im lokalen Bibliotheksbestand
verfügbar ist. Deshalb muss das Werk von der Heimatbibliothek des Benutzers
bei einer anderen Bibliothek bestellt und ausgeliehen werden. Der Benutzer muss das bestellte
Werk dann in seiner Heimatbibliothek abholen. Die Funktion Fernleihe ermöglicht
es dem Benutzer von seinem Heimatbibliotheksdienst aus diese Bestellung aufzugeben.
Der Benutzer sollte dabei angeben können wie er benachrichtigt werden will und wo er
den Titel abholt. Da die Fernleihe in der Regel nicht kostenlos ist, muss ausserdem die
Bezahlung geregelt werden.
Ergebnis:
Mit 2,5 erzielt das BIS das schlechteste Ergebnis. Nur wenig besser ist der SUB (2,83).
Am Besten schneidet der GBV mit 3,58 ab.
Analyse:
Die Fernleihe ist nicht in das BIS integriert. Der Benutzer kann aber den GBV für eine
Fernleihe nutzen. Dazu wird vom BIS aus verlinkt. Das Bezahlsystem für die Fernleihe ist
im BIS sehr umständlich gelöst und auch nicht eindeutig erklärt. Es gibt zwei Möglichkeiten
die Fernleihgebühren zu entrichten. Entweder man kauft in der Zentralbibliothek
147

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
Wertcoupons mit Zugangsnummer und Passwort, oder man bestellt per E-Mail Pincodes,
die allerdings auch vor Ort bezahlt werden müssen. Wenn die bestellten Werke eingetroen
sind, wird ein Vermerk im Benutzerkonto angezeigt und bei aktivierter E-Mail
Adresse eine Nachricht geschickt. Den Ort für die Zustellung/Abholung kann der Benutzer
in seinem Benutzerkonto einstellen. Diese Option ist allerdings auch schwer zu nden.
Dazu muss man zuerst die Kontoanzeige önen und ndet dort den Link persönliche
Einstellungen.
14.2.3. Logische und räumliche Trennung von eigenen und
fremden Inhalten
Beschreibung:
Dieses Kriterium beschreibt wie eigene Inhalte von fremden Angeboten abgegrenzt sind.
Es sollte z.B. nicht einfach auf fremde Inhalte verlinkt werden, ohne dies dem Benutzer
vorher deutlich anzuzeigen.
Ergebnis:
BIS und SUB trennen eigene und fremde Inhalte am Besten (3,08). Etwas schlechter
schneiden TIB (2,92) und GBV (2,67) ab.
Analyse:
Im BIS sind externe Links auch als solche gekennzeichnet und Ziel des Links wird angegeben.
14.2.4. Ergonomie
Beschreibung:
Mit diesem Kriterium soll erfasst werden, wie die Bibliothekdienste software-ergonomische
Gestaltungskriterien erfüllen. Dazu gehören Dialoggestaltung (Dialogführung, Strukturierung,
Orientierung, Navigation) und E/A-Gestaltung (Gestaltung, Farben, Darstellung).
Bei der Bewertung haben wir uns nicht explizit an die DIN gehalten. Der Vollständigkeit
halber hier aber eine Liste der wichtigsten Standards:
1. EN ISO 9241-11 (Gebrauchstauglichkeit)
2. EN ISO 9241-16:1999, EN ISO 9241-14:1997, EN ISO 9241-15:1997, EN ISO 9241-
17:1998 (Dialogführung)
3. EN ISO 9241-10, EN ISO 14915-1:2000 (Dialoggestaltung)
4. EN ISO 9241-8:1998 (Farbgestaltung)
Zu einer ergonomischen Lösung sollte auch das Angebot der Inhalte in englischer Sprache
gehören.
Ergebnis:
Das BIS schneidet mit 2,67 am schlechtesten ab. Der GBV ist mit 2,75 auch nur leicht
besser. Am besten erfüllen SUB (3,25) und TIB (3,33) das Ergonomie-Kriterium.
148

14.3. SUCHFUNKTION
Analyse:
Die Benutzerfreundlichkeit im BIS lässt sich an einigen Stellen verbessern. Beispielhaft für
die schlechte Navigation ist der Start einer Suche im Bestand der Universitätsbibliothek.
Auf der Startseite des BIS ndet sich die Bezeichnung Suche nur in Interne-Suche.
Die Internet-Suche führt aber aber ins WWW (Google, etc.) und nicht in den lokalen
Bestand der Bibliothek. Wenn der ungeübte Benutzer dann gemerkt hat, dass er hier
falsch ist, kehrt er auf die Startseite zurück und ihm sticht hoentlich das in groÿer blauer
Schrift geschriebene Wort Kataloge ins Auge (warum unter der Überschrift Kataloge der
Punkt Verlängerung/Kontoabfrage steht, ist mir auch nicht ganz klar). Weitere drei
Mausklicks später ist er bei der Suchmaske angelangt. Hätte der Benutzer allerdings den
in kleiner Schrift angezeigten Link im Menu auf der linken Seite gesehen, wäre er mit einem
Mausklick da gewesen. Es gibt mehrere Links, die entweder den gleichen Namen tragen
und an verschiedene Ziele führen (z.B. gibt es auch unter Internet-Suche noch einen
Link Kataloge, der wieder woanders hinführt), oder aber unterschiedliche Namen tragen
und an das gleiche Ziel führen (z.B. Kontoabfrage und Benutzungskonto). Verwirrend ist
auch, das das Farbschema des ORBIS völlig anders ist, als das Farbschema des BIS.
Benutzer, die der deutschen Sprache nicht mächtig sind, haben mit den Internetseiten
des BIS Probleme. Unter dem Link Englisch-Pages sind zwar allgemeine Informationen
auf Englisch zu nden und sogar Links mit englischen Bezeichnern. Die Linkziele (z.B.
ORBIS) sind dann allerdings wieder nur auf deutsch.
14.3. Suchfunktion
Zur Suchfunktion gehören 8 Kriterien. Die Einzelkriterien sind nochmals unterteilt in Art
der Suche, Suchraum und Medientyp. Die Ergebnisse liegen zwischen 1,67 und 4,25. Das
BIS erzielt zweimal die beste Wertung (Websuche, Medientyp Inhaltlich) und viermal die
Schlechteste (Explorative Suche, Globaler Suchraum, Suchkriterien, Medientyp Formal).
Die Suchmaske und die Suche im lokalen Bestand liegen im Mittelfeld. Bei der Suchfunktion
wurden teilweise sehr gute Ergebnisse erzielt. SUB und TIB verfügen über eine sehr
gute Funktion zur Beschränkung der Suche auf den eigenen Literaturbestand. Ausserdem
ist die Suche nach bestimmten Formaten bei SUB, GBV und TIB aussergewöhnlich gut.
Der explorativen Suche und der Möglichkeit zur Websuche wurde keine groÿe Relevanz
eingeräumt. Die Gewichtung liegt hier bei 2 bzw. 1. Alle anderen Kriterien sind mit 5
gewichtet. Die Art der Suche ist in drei Bereiche unterteilt: Die explorative Suche, die
Suche über eine Suchmaske und die Suche im WWW.
14.3.1. Explorative Suche
Beschreibung:
Bei einer explorativen Suche ist das eigentliche Suchziel noch unbekannt. Die Teilergebnisse
beeinussen den Suchverlauf. Dabei sucht der Benutzer einen Beitrag aus einem
Themenbereich (z.B. Genetik) und im Verlauf der Suche wird das Suchergebnis immer
mehr eingegrenzt (am Ende der Suche entscheidet sich der Benutzer evtl. für ein Buch
149

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
über genetische Suchalgorithmen). Die explorative Suche wurde nur mit 2 gewichtet.
Ergebnis:
Die Möglichkeit der explorativen Suche ist bei keinem Kandidaten besonders gut umgesetzt.
Am besten bieten SUB und TIB diese Funktion an (2,5). Der GBV erzielt einen
ähnlichen Wert. Das BIS erhält nur 1,75 Punkte und schneidet am schlechtesten ab.
Analyse:
Beim BIS ist keine explorative Suche möglich.
14.3.2. Suchmaske
Beschreibung:
Die Suchmaske ist eine elementare Funktion in einem Bibliotheksdienst. Dem Benutzer
sollten zwei Suchmasken angeboten werden. Einerseits eine einfache Suchmaske nur mit
den wichtigsten Suchparametern für schnelle Abfragen und andererseits eine erweiterte
Suchmaske mit zahlreichen Suchparametern für komplexe Suchanfragen.
Ergebnis:
Alle untersuchten Bibl. sind mit befriedigenden/guten Noten bewertet worden. Die beste
Suchmaske hat der GBV (3,75). Etwas schlechter sind BIS (3,25) und TIB (3,17).
Analyse:
Beim BIS gibt es sowohl eine einfache, als auch eine erweiterte Suchmaske. Beide Suchmasken
sind intuitiv zu verstehen und zu benutzen.
14.3.3. Websuche
Beschreibung:
Mit der Websuche kann der Benutzer seinen Suchraum über den Bibliotheksdienst auf
das WWW ausweiten. Dazu werden Schnittstellen/Links auf Suchmaschinen angegeben
(z.B. Google). Diese Funktion wurde nur mit einer 1 gewichtet.
Ergebnis:
Alle Ergebnisse sind bestenfalls ausreichend. Die Möglichkeit zur Websuche ist am Besten
vom BIS umgesetzt (2,25). Die drei anderen Kandidaten haben fast den gleichen Wert
(ca. 1,7).
Analyse:
Im BIS gibt es eine umfangreiche Linksammlung, die bei einer Suche im WWW helfen
soll. Die Links sind zwar etwas unübersichtlich dargestellt, aber gut dokumentiert.
14.4. Suchraum
Der Suchraum ist unterteilt in die Teilkriterien Global, Lokal und Suchkriterien.
150

14.4. SUCHRAUM
14.4.1. Global
Beschreibung:
Bei einer globalen Suche kann der Benutzer nicht nur in dem Bestand seiner Heimatbibliothek
recherchieren, sondern kann die Suche auch auf andere Bibliothekskataloge
ausweiten.
Ergebnis:
Der GBV lässt sich am besten zum Suchen im globalen Suchraum verwenden (3,83). Wesentlich
schlechter ist das BIS (2,5). Die anderen beiden Kandidaten sind aber immerhin
noch mit einem befriedigend gutem Ergebnis bewertet (SUB 3 und TIB 3,42).
Analyse:
Der Suchraum im BIS lässt sich nicht über die Bestände der Universitäts-Bibliothek und
der Landesbibliothek hinaus erweitern. Für Recherchen im Bestand anderer Bibliotheken
muss der GBV verwendet werden.
14.4.2. Lokal
Beschreibung:
Bei einer lokalen Suche kann der Benutzer die Suche nur auf den Bestand seiner Heimatbibliothek
beschränken.
Ergebnis:
Bei diesem Kriterium erzielen SUB und TIB ein sehr gutes Ergebnis (4,17). Die lokale
Suche im BIS ist mit 3,5 gut bewertet. Ein schlechtes Ergebnis erzielt dagegen der GBV
(2,5).
Analyse:
Die Suche im BIS ist auf defaultmäÿig auf die Bestände von Universitätsbibliothek und
Landesbibliothek beschränkt. In der erweiterten Suchmaske gibt es noch einige weitere
Optionen zum Suchraum. Man kann aber z.B. die Suche nicht nur auf den Bestand der
Universitätsbibliothek beschränken.
14.4.3. Suchkriterien
Beschreibung:
Der Suchraum sollte vom Benutzer anhand von Angaben zu bestimmten Suchkriterien
einschränkbar sein (zumindest in der erweiterten Suchmaske). Die Projektgruppe hat die
wichtigsten Suchkriterien, die vorhanden und auswählbar sein sollten, festgelegt: Sprache,
Titel, Autor, Erscheinungsdatum, Gegenstand der Suche, ISBN, Schlagwörter, Verlag.
Ergebnis:
Alle Kandidaten erzielen befriedigende bis gute Ergebnisse. Der SUB liegt mit 3,93 Punkten
an erster Stelle. GBV (3,75) und TIB (3,83) sind ähnlich gut. Etwas abgeschlagen ist
das BIS mit 3,25 Punkten.
Analyse:
In der erweiterten Suchmaske des BIS kann man folgende Suchkriterien auswählen: Ti-
151

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
telstichwörrter (Bücher/Medien), Titelstichwörrter (Zeitschriften), Titelstichwörter (Serien),
Titel (Phrase), Titel (genau), Freitext (überall), Personen, Institutionen/Kongress,
ISBN/ISSN, Schlagwörter, Systemstelle (BIS), Erscheinungsjahr und in welchen Medien
gesucht werden soll. Es können auch drei verschiedene Kriterien mit und/oder verknüpft
werden. Damit lassen sich bis auf die Sprache und den Verlag alle geforderten Kriterien
einstellen.
14.5. Medientyp
Beim Medientyp wird zwischen dem Format des Mediums und dem Inhalt unterschieden.
14.5.1. Formal
Beschreibung:
Mit dieser Funktion lässt sich der Suchraum auf Medien eines bestimmten Formates eingrenzen.
Unter Format ist z.B. Audio, Video oder Text zu verstehen.
Ergebnis:
SUB (4,25), TIB (4,17) und GBV (4,0) erzielen gute bis sehr gute Ergebnisse. Wesentlich
schlechter ist dagegen das BIS mit einem befriedigenden Wert (3,17).
Analyse:
Die Festlegung der Suche auf ein bestimmtes Format ist im BIS nur ansatzweise umgesetzt.
In der erweiterten Suche kann der Benutzer bezüglich des Formates unter folgenden
Kriterien auswählen: in allen Medien, audio-visuelle Materialien, kartographische Medien,
Zeitschriften und Mediatheksbestand. Diese Kriterien sind aber vermischt mit inhaltlichen
Kriterien und Ortsangaben. Die Vermischung von Suchkriterien unterschiedlicher Kategorien
erschwert es, zu einem schnellen Ergebnis zu gelangen.
14.5.2. Inhaltlich
Beschreibung:
Ein bestimmter Medientyp lässt sich auch über den Inhalt festlegen. Mit Inhalt ist z.B.
Diplomarbeit oder Essay gemeint.
Ergebnis:
Bei diesem Kriterium erzielen alle Kandidaten ähnliche Ergebnisse. Am besten schneiden
BIS und SUB ab (3,67). Leicht schlechter sind TIB (3,33) und GBV (3,08).
Analyse:
Die Auswahl von Suchkriterien, die sich auf den Inhalt des Werkes beziehen ist im BIS
nur teilweise möglich. In der erweiterten Suche kann der Benutzer unter folgenden Kriterien
auswählen: Dissertationen und Habilitationsschriften, Dipl.-, Mag.- und Ex.-Arbeiten
(Univ. Oldenburg), Kinderbücher (Universitätsbibliothek), Oldenburgica (LandesB.), Niederdeutsche
Literatur (LandesB.), Schulbücher (Universitätsbibl.) und Noten (Universitätsbibl.).
Diese Kriterien sind aber vermischt mit formalen Kriterien und Ortsangaben.
152

14.6. SUCHMASKE
Die Vermischung von Suchkriterien unterschiedlicher Kategorien erschwert die Auswahl
passender Suchkriterien.
14.6. Suchmaske
Das Kriterium Suchmaske bewertet, in wie weit die Suchkriterien dem Nutzer als wählbare
Optionen angeboten werden. Da die Suchmaske entscheidend für die Benutzung des
Bibliotheksangebots ist, ist die Gewichtung der Kriterien entsprechend hoch. Nur zusätzliche
Services wie Suchassistent und Nutzerklassen werden als weniger wichtig(Gewichtung
von 3 bzw. 2) eingestuft.
14.6.1. Nutzung aller möglichen Suchkriterien
Beschreibung:
Wieviele und welche der Suchkriterien stellt die Suchmaske zur Verfügung? Kann der
Nutzer durch Auswahl/Einschränkung der Kriterien seine Suchanfrage individuell zusammenstellen?
Ergebnis:
Das BIS bekommt eine Durchschnittsnote von 2.75 für die individuelle Zusammenstellbarkeit,
die anderen Bibliotheken liegen zwischen 3.5 und 3.7, also fast eine Note besser.
Bei Einschränkung/Auswahl der Kriterien wird das BIS mit 3.33 bewertet, die anderen
Angebote bekommen Noten von 3.75(SUB), 3.83(GBV) und 3.67(TIB), also leicht besser.
Analyse:
Das BIS schneidet von allen untersuchten Bibliotheken am schlechtesten ab. Es wird eine
einfache und eine erweiterte Suche angeboten. Die einfache Suche bietet ein Eingabefeld
und die Möglichkeit, den Suchbegri als Titel oder Autor oder als Schlagwort zu klassizieren.
Bei der erweiterten Suche können drei Eingaben gemacht werden, die untereinander
logisch verknüpft und jeweils einem Suchfeld zugeordnet werden können. Weitere Optionen
sind Erscheinungsjahr(ist, ist neuer als, ist älter als, liegt zwischen) und die Auswahl
des Medientyps (s.dort).
14.6.2. Nutzerklassen
Beschreibung:
Wird zwischen Nutzerklassen unterschieden, also erfahrenen Nutzern die erweiterte, unerfahrenen
die einfache Suche als Standard präsentiert.
Ergebnis:
Keine der untersuchten Systeme bietet einen solchen Service.
14.6.3. Suchassistent
Beschreibung:
Gibt es einen Suchassistenten, der den Nutzer bei den Schritten seiner Suche erklärend
153

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
begleitet.
Ergebnis:
Keine der untersuchten Systeme bietet einen Assistenten.
14.6.4. Auswahl des Suchraums
Beschreibung: Lässt sich der Suchraum eingrenzen bzw. erweitern, kann man also nur
in den tatsächlichen Beständen der Bibliothek suchen oder hat man die Möglichkeit, zu
durchsuchende Bibliotheken(z.B. für Fernleihe) auszuwählen?
Ergebnis:
Das BIS wird ähnlich wie die anderen Bibliotheken mit 2.92 bewertet.
Analyse:
Das BIS bietet nicht die Möglichkeit, den Suchraum zu verändern. Standardmäÿig wird
in den Beständen der Standorte Uhlhornsweg und Wechloy, der Landesbibliothek und der
FH gesucht. Für eine Fernleihe muss seperat im GBV-Katalog gesucht werden.
14.6.5. Auswahl der Medientypen
Beschreibung: Hat der Nutzer die Möglichkeit festzulegen, welche Medientypen in seinem
Ergebnis angezeigt bzw. welche ausgeschlossen werden sollen
Ergebnis:
Hier schneidet das BIS mit einem Wert von 2.67 deutlich schlechter ab als die anderen
Bibliotheken mit Noten über 4.
Analyse:
Die erweiterte Suchmaske des BIS ermöglicht die Auswahl des Medientyps, allerdings
lässt sich nur ein Medientyp festlegen, nachdem gesucht werden soll. Kombinationen bzw.
Abwahl bestimmter Typen sind möglich.
SUB, GBV und TIB bieten wesentlich weitergehende Optionen. Alle vorhandenen Medientypen
werden aufgelistet und lassen sich durch Checkboxes an- oder abwählen, so
dass jeder Nutzer die von ihm im Ergebnis gewünschten Typen zusammen stellen kann.
14.7. Ergebnispräsentation
Das Kriterium Ergebnispräsentation bewertet, wie das Ergebnis einer Suchanfrage dargestellt
wird und welche Möglichkeiten dem Nutzer angeboten werden, diese Darstellung
nach seinen Interessen zu verändern.
14.7.1. Sortierung
Beschreibung:
Wird das Suchergebnis sortiert und falls ja, nach welchen Aspekten? Kann der Nutzer
wählen, ob nach Titel, Autor, Erscheinungsjahr(Aktualität) auf- oder absteigend sortiert
154

14.7. ERGEBNISPRÄSENTATION
wird? Gibt es eine Relevanzbewertung der Ergebnisse, so dass der Nutzer die besten
Treer als erstes präsentiert bekommt? Werden persönliche Prole erstellt, nach denen
die Relevanz der Suchergebnisse bewertet werden(was sucht der Nutzer sonst? Welchem
Fachbereich gehört er an?)
Ergebnis:
In allen drei Kriterien bekommt das BIS nur niedrige Noten(

KAPITEL 14. BEWERTUNG VON BESTEHENDEN BIBLIOTHEKSDIENSTEN
Gibt es das Buch als elektronische Ressource? Falls ja, unter welchen Voraussetzungen
kann der Nutzer sie ausleihen?
Wie werden die Ergebnisse sortiert, wenn in mehreren Bibliotheken gesucht wurde?
Ergebnis:
Das BIS bekommt durchschnittliche Noten für die Kriterien wo/wieviel(3) und Status(3.67).
Für die Sortierung nach Verfügbarkeit(1.67), Fernleihe(2.58) und Verfügbarkeit in digitalen
Bibliotheken(1.33) schlechtere Werte. SUB, TIB und GBV erhalten ähnliche Noten.
Nur die Suche in digitalen Bibliotheken wird bei den anderen eindeutig besser bewertet.
Die Fernleihe ist natürlich beim GBV am besten.
Analyse:
Das BIS zeigt erst in der Vollanzeige, ob ein Medium ausleihbar ist und wo es wieviele
Exemplare davon gibt. Es wird nicht nach Verfügbarkeit sortiert und auch keine Fernleihemöglichkeiten
angezeigt. Bei Verfügbarkeit in digitalen Bibliotheken, für die die Uni
eine Lizenz besitzt, verweist ein Link auf den Artikel. Um ihn zu lesen, muss man sich
allerdings innerhalb des Uni-Netzwerks benden.
Bei SUB, GBV und TIB werden mehr elektronische Ressourcen gefunden und per Link
zugänglich gemacht.
156

15. Anforderungsdenition
15.1. Ausgangssituation, Zielsetzung
Die zügige Entwicklung des Internets und der Informationstechnologie führen zwangsläu-
g zu groÿen Veränderungen in den Bereichen des Studiums, der Lehre, Forschung und
Fortbildung. Aus diesem Grund ist in Zukunft der optimale Einsatz von Informationstechnologie
ein wichtiger Aspekt im Wettbewerb der Hochschulen.
Zunehmend werden neben Vorlesungen und Seminaren auch digitale Medien zur Fortbildung
verwendet, wofür eigens Lernmanagementsysteme als Plattformen an den Hochschulen
eingeführt wurden, die allerdings nicht so intensiv in Anspruch genommen werden, wie
dies im Ausland oft der Fall ist.
Seit einiger Zeit arbeiten deutsche Hochschulen, so auch die Universität Oldenburg, an
einem i 3 sic!-Entwicklungsprojekt (Integrierte Informationsinfrastruktur - service information
communication!) zur Einführung integrierter Arbeitsumgebungen, welche durch
Beseitigung gegenwärtiger Redundanzen in der Datenpege und Minimierung von Schnittstellenproblemen
zwischen aktuell parallel existierenden, inkompatiblen Systemen die Ef-
zienz der Arbeitsabläufe steigern sollen. Unter anderem geschieht dies in Oldenburg in
Form eines Studierendenportals, welches die Produktion wissenschaftlicher Information
und die Kommunikation in Gruppen vereinfachen soll.
Ein Vorteil dieser Portal-Neuentwicklung ist, dass die Studierenden und Mitarbeiter alle
Online-Angebote der Universität in Zukunft nicht wie bisher auf verschiedenen Websites
mit jeweils eigenständigen Nutzerverwaltungen und Datenhaltungen, sondern einheitlich
im Rahmen des Portals angeboten bekommen. Die durch eine zentrale Rechte- und Nutzerverwaltung
angebotene Single Sign On-Funktion erleichtert die Inanspruchnahme aller
integrierten Dienste. Auÿerdem können dank der Personalisierung des Portals dessen
Inhalte und Aussehen von jedem Nutzer individuell angepasst werden.
Nähere Informationen zum i 3 sic-Portal-Entwicklungsprojekt können im dazugehörigen
Projektbericht nachgelesen werden.
Für dieses Studierendenportal der Universität Oldenburg sollen durch diese Projektgruppe
Bibliotheksdienste entwickelt werden. Zu den Hauptzielen der Projektgruppe zählen neben
der in Form mehrerer Portlets vorgesehenen Einbindung des Oldenburger Bibliotheks-
Informationssystems (BIS) ins Portal auch die Erweiterung des Zugris der BIS-Suchfunktion
auf externe Quellen, wie beispielsweise digitale Bibliotheken, und die damit verbundene
Umstrukturierung der Suche.
So wurde aus einem von der Projektgruppe erstellten Kriterienkatalog, in welchem die
Gruppenmitglieder eine Auswahl relevanter Anforderungen stellten und diese im gegen-
157

KAPITEL 15. ANFORDERUNGSDEFINITION
wärtigen BIS-Onlinesystem und in vergleichbaren externen Angeboten bewerteten, diese-
Anforderungsdenition an das zu entwickelnde Projekt erstellt.
Im Vordergrund der Entwicklung stehen Benutzerfreundlichkeit, eine eektive Suche und
eine sinnvolle Präsentation der Suchergebnisse. Zudem sollen die BIS-Benutzerkonten im
Zuge der Umstellung auf das Portal abgelöst werden.
15.2. Systemeinsatz und Zielumgebung
Das System wird in das Open-Source Portal Liferay als Teil eines Studierendenportals integriert
werden. Liferay basiert auf Java und ist deshalb plattformunabhängig einsetzbar.
Über das Studierendenportal werden den Studenten die bisher voneinander getrennt angebotenen
Dienste (z.B. StudIP, Bibliothek und E-Mail) zusammen und per Single-Sign-On
zur Verfügung gestellt. Damit das System möglichst unabhängig vom verwendeten Portal
eingesetzt werden kann, wird die Bibliotheksfunktion mit JSR-168-konformen Portlets implementiert
werden. Die Portlets können dabei wiederum andere Java-Technologien (z.B.
JSP, EJB) verwenden.
Die Bibliotheksfunktion wird auf der von der Bibliothek Oldenburg verwendeten Software
URICA aufsetzen. URICA stellt verschiedene Schnittstellen zur Verfügung. Das von
der Projektgruppe zu entwickelnde System wird nicht für administrative Aufgaben der
Bibliothek (z.B. neue Bücher anlegen, Metadaten bearbeiten) verwendet werden.
15.3. Funktionale Anforderungen
Dieses Kapitel befasst sich mit den funktionalen Anforderungen, die an das zu entwickelnde
Softwaresystem gestellt werden und nimmt somit eine Konkretisierung des in den
Zielbestimmungen (siehe Kapitel 1) denierten Funktionalitätsumfangs vor. Dazu ndet
zunächst in Abschnitt 15.3.1 eine Betrachtung der angestrebten Nutzerklassen statt. Im
Anschluss daran werden in Abschnitt 15.3.2 mögliche Anwendungsfälle identiziert und
in vier übergeordnete Funktionalitätsklassen eingeordnet. Abschlieÿend werden die einzelnen
Anwendungsfälle - gegliedert nach den vier Funktionalitätsklassen Suchen, Beschaen,
Benutzerkonto verwalten und Onlinehilfe aufrufen - in den Abschnitten 15.3.3 bis 15.3.3
detailliert beschrieben.
15.3.1. Benutzerklassen
Zunächst sind für das System zwei Benutzerklassen vorgesehen:
• Authentizierter Benutzer: Authentizierte Benutzer sind Benutzer mit Account
im Studierendenportal, die üblicherweise auch schon im BIS registriert sind.
Zu dieser Klasse zählen im Allgemeinen Studenten, Mitarbeiter und Lehrende der
Universität Oldenburg sowie die Administratoren des Systems selbst.
158

15.3. FUNKTIONALE ANFORDERUNGEN
• Gast: Gäste erhalten ohne Account und Rechte Zugri auf eine Teilmenge des
vollständigen Funktionalitätsumfangs.
15.3.2. Anwendungsfälle
Der Entwurf und die Integration von verschiedenen Bibliotheksdiensten in ein sich in
der Entwicklungsphase bendendes Web-Portal erfordern die Berücksichtigung zahlreicher
Funktionalitäten. Diese Funktionalitäten sollen einem Nutzer des Portals die Arbeit
und die Interaktion mit verschiedenen Bibliotheken insbesondere der Universitätsbibliothek
Oldenburg, aber auch anderer Bibliotheken, Verbundsystemen und digitaler Bibliotheken
erleichtern und diverse Dienste online zugänglich machen. Die zu realisierenden
Funktionalitäten können in vier Kategorien eingeteilt werden. Am Anfang nahezu jeder
Nutzung von Online-Bibliotheksdiensten steht die Recherche nach den gewünschten Dokumenten.
Dieses breite Aufgabenfeld liefert dann oft in Form von grasch aufbereiteten
Suchergebnissen die Ausgangsbasis für weitere Aktivitäten, die im Bereich der Beschaffung
von Dokumenten liegen. Unverzichtbar ist auch ein komfortables Benutzerkonto, in
dem Funktionalitäten rund um das Einsehen von Ausleihstatus, Gebühren, Nachrichten
oder das Kongurieren des eigenen Prols angeboten werden sollen. Alle Funktionalitäten
werden durch eine Onlinehilfe unterstützt, die den vierten Funktionalitätsblock bildet. Sie
soll den Benutzer in verschiedenen Formen beim Umgang mit dem System unterstützen.
Jede der vier Funktionalitätsklassen setzt sich also aus verschiedenen Funktionalitäten
zusammen, die aus der folgenden Liste zu entnehmen sind.
• Suchen
Einfaches Suchen
Erweitertes Suchen
• Beschaen
Dokument vorbestellen
Dokument fernleihen
Dokument aus digitaler Bibliothek beziehen
• Benutzerkonto verwalten
Registrierung bei Bibliothekssystemen
Dokumente einsehen
∗ Geliehene Dokumente einsehen
∗ Vorbestellungen einsehen
∗ Vormals geliehene Dokumente einsehen
Gebühren einsehen
Benachrichtigungen einsehen
Ausleihe verlängern
Prol einstellen
• Onlinehilfe aufrufen
Tutorial lesen
159

KAPITEL 15. ANFORDERUNGSDEFINITION
Kontextsensitive Online-Hilfe benutzen
Live Chat betreten
Das Use-Case-Diagramm in Abbildung 15.1 veranschaulicht die Gruppierung der Funktionalitäten
noch einmal grasch und deniert zugleich, welche Bibliotheksdienste für das
Studierendenportal zu entwickeln und anzubieten sind.
Abbildung 15.1.: UML Anwendungsfalldiagramm des zu entwickelnden Systems
160

15.3. FUNKTIONALE ANFORDERUNGEN
15.3.3. Funktionalität
Im folgenden wird nun auf die vier identizierten Funktionalitätsklassen genauer eingegangen.
Dazu wird jeder Anwendungsfall einer Klasse in Form einer tabellarischen Übersicht
im Detail beschrieben.
Suchen
ANWENDUNGSFALL
Einfaches Suchen
ZWECK
Einfache, schwach parametrisierbare Suche
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
Benutzer möchte eine einfache Suche durchführen
VORBEDINGUNGEN
Einfache Suchmaske wurde geönet
RELEVANTE EINGABEDATEN
Eine einfache Suchanfrage in Form eines oder mehrerer Schlag- bzw. Suchworte und
einer Möglichkeit der Einschränkung des Suchraums
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Suchergebnis in tabellarischer Form mit Optionen zur Änderung
der Sortierung der Suchergebnisse sowie Detailansichten einzelner Einträge angezeigt.
Für authentizierte Benutzer wird zudem eine Nutzung weiterer Funktionalitäten, wie
z.B. Vormerken, Fernleihen usw. angeboten
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer önet einfache Suchmaske
2. Beutzer gibt Suchbegri(e) ein
3. Benutzer schränkt ggf. den Suchraum ein
4. Benutzer führt Suche nach Abschluss seiner Eingaben aus
5. Benutzer sieht die ermittelten Suchergebnisse (siehe Ergebnis) ein
6. Benutzer ändert ggf. die Sortierung der Suchergebnisse
7. Benutzer lässt sich die Detailangaben zu einem Dokument anzeigen
161

KAPITEL 15. ANFORDERUNGSDEFINITION
ANWENDUNGSFALL
Erweitertes Suchen
ZWECK
Komplexe, stark parametrisierbare Suche
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
Benutzer möchte erweiterte Suche durchführen
VORBEDINGUNGEN
Erweiterte Suchmaske wurde geönet
RELEVANTE EINGABEDATEN
Eine komplexe Suchanfrage unter Angabe diverser Suchparameter, wie z.B. Titel, Autor(en),
Verlag, Erscheinungsjahr usw., und expliziter Auswahlmöglichkeiten von Dokumenttypen
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Suchergebnis in tabellarischer Form mit Optionen zur Änderung
der Sortierung der Suchergebnisse sowie Detailansichten einzelner Einträge angezeigt.
Für authentizierte Benutzer wird zudem eine Nutzung weiterer Funktionalitäten, wie
z.B. Vormerken, Fernleihen usw. angeboten
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer önet einfache Suchmaske
2. Beutzer gibt diverse Suchbegri(e) ein (siehe relevante Eingabedaten)
3. Benutzer schränkt ggf. den Suchraum und den Dokumenttyp ein
4. Benutzer führt Suche nach Abschluss seiner Eingaben aus
5. Benutzer sieht die ermittelten Suchergebnisse (siehe Ergebnis) ein
6. Benutzer ändert ggf. die Sortierung der Suchergebnisse
7. Benutzer lässt sich die Detailangaben zu einem Dokument anzeigen
162

15.3. FUNKTIONALE ANFORDERUNGEN
Beschaen
ANWENDUNGSFALL
Dokument vorbestellen
ZWECK
Vorbestellung eines Dokuments zur späteren Abholung in der Bibliothek
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte ein Dokument vorbestellen
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Eine Suche (einfach oder erweitert) wurde durchgeführt
• Das betreende Dokument wurde gefunden
• Das betreende Dokument steht zur Vorbestellung zur Verfügung
RELEVANTE EINGABEDATEN
Funktionalität operiert auf bereits gewähltem Dokument. Keine weiteren Eingabedaten
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Meldung über erfolgreich im Bibliothekssystem abgesetzte Vorbestellung
NACHBEDINGUNGEN
• Vorbestellung kann im Benutzerkonto eingesehen werden
• Vorbestellung ist im Bibliothekssystem abgesetzt
SZENARIO
1. Benutzer führt einfache oder erweiterte Suche durch
2. Benutzer wählt Funktionalität zur Vorbestellung eines als Suchergebnis angezeigten
Dokuments
163

KAPITEL 15. ANFORDERUNGSDEFINITION
ANWENDUNGSFALL
Dokument fernleihen
ZWECK
Ausleihe eines Dokuments aus entfernter Bibliothek über lokale Bibliothek
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte Dokument ausleihen, dass in lokaler Bibliothek nicht vorrätig ist
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Eine Suche (einfach oder erweitert) wurde durchgeführt
• Das betreende Dokument wurde gefunden
• Das betreende Dokument steht zur Fernleihe zur Verfügung
RELEVANTE EINGABEDATEN
Funktionalität operiert auf bereits gewähltem Dokument. Keine weiteren Eingabedaten
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Meldung über erfolgreich eingeleitete Fernleihe
NACHBEDINGUNGEN
Auftrag zur Fernleihe bendet sich im Bibliothekssystem
SZENARIO
1. Benutzer führt einfache oder erweiterte Suche durch
2. Benutzer wählt Funktionalität zur Fernleihe eines als Suchergebnis angezeigten Dokuments
164

15.3. FUNKTIONALE ANFORDERUNGEN
ANWENDUNGSFALL
Dokument aus digitaler Bibliothek beziehen
ZWECK
Übertragung einer Dokumentdatei auf den Rechner des Benutzers
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
• Benutzer möchte in freier digitaler Bibliothek bendliches Dokument sofort digital
beziehen
• Authentizierter Benutzer möchte in anmeldepichter Bibliothek bendliches Dokument
sofort digital beziehen
VORBEDINGUNGEN
• Benutzer ist authentiziert (im Falle von anmeldepichtiger digitaler Bibliothek)
• Eine Suche (einfach oder erweitert) wurde durchgeführt
• Das betreende Dokument wurde gefunden
• Das betreende Dokument steht zum direkten Download aus digitaler Bibliothek zur
Verfügung
RELEVANTE EINGABEDATEN
Funktionalität operiert auf bereits gewähltem Dokument. Keine weiteren Eingabedaten
AUSNAHMEN
Fehler beim Übertragen des Dokuments
ERGEBNIS
Dokumentdatei bendet sich auf dem lokalen Rechner des Benutzers
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer führt einfache oder erweiterte Suche durch
2. Benutzer wählt Funktionalität zum Beziehen der Dokumentdatei aus digitaler Bibliothek
3. Benutzer wählt lokalen Pfad zur Speicherung des Dokuments
4. Dokument wird übertragen
165

KAPITEL 15. ANFORDERUNGSDEFINITION
Benutzerkonto verwalten
ANWENDUNGSFALL
Registrierung bei Bibliothekssystemen
Dieser Anwendungsfall soll übergangsweise realisiert werden. Die betreende Funktionalität
soll ggf. später von einem übergeordneten Identity Management System ersetzt werden.
ZWECK
Ermöglichung des Zugris auf ein Bibliothekssystem, das eine Anmeldung erfordert
AKTEURE
Authentizierter Benutzer
EREIGNIS
• Benutzer möchte Funktionalität nutzen, die eine vorhandene Registrierung bei einem
Bibliothekssystem voraussetzt und wird daher zunächst zu diesem Anwendungsfall
umgeleitet
• Benutzer möchte aktiv Registrierungsdaten für Bibliothekssystem eingeben
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Registrierungsfunktionalität selektiert
RELEVANTE EINGABEDATEN
Nutzerdaten (abhängig vom jeweiligen Bibliothekssystem)
AUSNAHMEN
Fehler bei Verbindung zu betreendem Bibliothekssystem
ERGEBNIS
Benutzer bekommt Meldung über erfolgreiche Registrierung bei dem betreenden Bibliothekssystem
NACHBEDINGUNGEN
Registrierungsinformationen sind gespeichert, sodass Funktionalitäten, die eine vorhandene
Registrierung bei einem Bibliothekssystem voraussetzen, benutzbar sind
SZENARIO
• Benutzer führt einfache oder erweiterte Suche durch
• Benutzer wählt Funktionalität die eine vorhandene Registrierung bei einem Bibliothekssystem
voraussetzt
• Registrierung bei Bibliothekssystem wird vorgeschaltet
• Gewünschte Funktionalität kann genutzt werden
166

15.3. FUNKTIONALE ANFORDERUNGEN
ANWENDUNGSFALL
Gebühren einsehen
ZWECK
Nutzer kann sich über angefallene Gebühren informieren
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte sich über angefallene Gebühren informieren
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen der Gebühren selektiert
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt eine Aufstellung über angefallene Gebühren angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von angefallenen Gebühren
ANWENDUNGSFALL
Benachrichtigungen einsehen
ZWECK
Benutzer kann Benachrichtigungen, wie z.B. Mahnungen oder Hinweise auf demnächst
wieder abzugebene Dokumente einsehen
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte Benachrichtigungen einsehen
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen von Benachrichtigungen selektiert
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Benachrichtigungen angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von Benachrichtigungen
167

KAPITEL 15. ANFORDERUNGSDEFINITION
ANWENDUNGSFALL
Ausleihe verlängern
ZWECK
Verlängerung der Abgabefrist eines geliehenen Dokuments
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte ein Dokument über die momentane Abgabefrist hinaus behalten
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen von geliehenen Dokumenten selektiert
• Benutzer hat bestimmtes Dokument selektiert
RELEVANTE EINGABEDATEN
Funktionalität operiert auf bereits gewähltem Dokument. Keine weiteren Eingabedaten
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Meldung über die erfolgreich verlängerte Abgabefrist
NACHBEDINGUNGEN
Fristverlängerung wurde im Bibliothekssystem eingepegt
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von Geliehenen Dokumenten
3. Benutzer wählt bestimmtes Dokument
4. Benutzer wählt die Funktionalität zur Verlängerung der Ausleihe
5. Ausleihe wird verlängert
168

15.3. FUNKTIONALE ANFORDERUNGEN
ANWENDUNGSFALL
Prol einstellen
ZWECK
Benutzer kann Prol spezizieren, so dass die Ergebnispräsentation von Suchanfragen
an seine persönlichen Verhältnisse angepasst wird
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte Prol angeben
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einstellen des Prols selektiert
RELEVANTE EINGABEDATEN
Angabe von benutzerspezischen Daten bzgl. individueller Präferenzen bei der Dokumentensuche
u. ä.
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt erfolgreich eingestelltes Benutzerprol angezeigt
NACHBEDINGUNGEN
Benutzerprol ist persistent gespeichert und kann für Personalisierungszwecke vom System
genutzt werden
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Einstellung seines Prols
3. Benutzer stellt Prol ein
169

KAPITEL 15. ANFORDERUNGSDEFINITION
Dokumente einsehen
ANWENDUNGSFALL
Geliehene Dokumente einsehen
ZWECK
Benutzer kann seine aktuell ausgeliehenen Dokumente einsehen
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte seine aktuell ausgeliehenen Dokumente einsehen
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen geliehener Dokumente selektiert
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Übersicht mit seinen aktuell ausgeliehenen Dokumenten angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von Dokumenten
3. Benutzer wählt Funktionalität zur Anzeige von ausgeliehenen Dokumenten
170

15.3. FUNKTIONALE ANFORDERUNGEN
ANWENDUNGSFALL
Vorbestellungen einsehen
ZWECK
Benutzer kann seine aktuell vorbestellten Dokumente einsehen
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte seine aktuell vorbestellten Dokumente einsehen
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen vorbstellter Dokumente selektiert
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Übersicht mit seinen aktuell vorbestellten Dokumenten angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von Dokumenten
3. Benutzer wählt Funktionalität zur Anzeige von vorbestellten Dokumenten
ANWENDUNGSFALL
Vormals geliehene Dokumente einsehen
ZWECK
Benutzer kann seine vormals ausgeliehenen Dokumente einsehen
AKTEURE
Authentizierter Benutzer
EREIGNIS
Benutzer möchte seine vormals ausgeliehenen Dokumente einsehen
VORBEDINGUNGEN
• Benutzer ist authentiziert
• Benutzer hat das Benutzerkonto geönet
• Benutzer hat die Funktionalität zum Einsehen vormals Dokumente selektiert
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler bei Verbindung zu Bibliothekssystem
ERGEBNIS
Benutzer bekommt Übersicht mit seinen vormals ausgeliehenen Dokumenten angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer wählt Benutzerkonto
2. Benutzer wählt Funktionalität zur Anzeige von Dokumenten
3. Benutzer wählt Funktionalität zur Anzeige von vormals ausgeliehenen Dokumenten
171

KAPITEL 15. ANFORDERUNGSDEFINITION
Onlinehilfe aufrufen
ANWENDUNGSFALL
Tutorial lesen
ZWECK
Benutzer kann sich in einem Tutorial über die Anwendung des Systems informieren
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
Benutzer hat allgemeine Probleme im Umgang mit dem System
VORBEDINGUNGEN
keine
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
keine
ERGEBNIS
Benutzer bekommt Tutorial angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer hat ein allgemeines Problem im Umgang mit dem System
2. Benutzer ruft das Tutorial auf
3. Benutzer kann sein Problem ggf. mit Hilfe des Tutorials lösen
ANWENDUNGSFALL
Kontextsensitive Online-Hilfe benutzen
ZWECK
Benutzer kann abhängig von seiner Position im System ein Hilfesystem benutzen
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
Benutzer hat Probleme im Umgang mit einem bestimmten Teil des Systems
VORBEDINGUNGEN
keine
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
keine
ERGEBNIS
Benutzer bekommt abhängig von seiner Position im System Hilfe angezeigt
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer hat ein Problem im Umgang mit einem bestimmten Teil des Systems
2. Benutzer ruft die kontextsensitive Hilfe auf
3. Benutzer kann sein Problem ggf. mit Hilfe der kontextsensitiven Hilfe lösen
172

15.4. NICHTFUNKTIONALE ANFORDERUNGEN
ANWENDUNGSFALL
Live Chat betreten
ZWECK
Benutzer kann sich mit Mitarbeitern der Bibliothek und ggf. anderen Benutzern austauschen
AKTEURE
Gast, authentizierter Benutzer
EREIGNIS
Benutzer möchte sich mit Mitarbeitern der Bibliothek und ggf. anderen Benutzern
austauschen
VORBEDINGUNGEN
keine
RELEVANTE EINGABEDATEN
keine
AUSNAHMEN
Fehler beim betreten des Live-Chat-Systems
ERGEBNIS
Benutzer bendet sich in Chatroom
NACHBEDINGUNGEN
keine
SZENARIO
1. Benutzer sucht direkten Kontakt zu einem Bibliothekaren oder einem anderen Benutzer
2. Benutzer betritt den Live-Chat
15.4. Nichtfunktionale Anforderungen
Wichtige Anforderungen sind vor allem:
• Ausfallsicherheit: beschreibt die Wahrscheinlichkeit des Versagens eines Systems
während des Betriebes.
• Effizienz: bezeichnet die Performanz von Programmen und Hardware bezüglich des
Resourcenverbrauchs und der Qualität der Ausgabe.
• Übersichtlichkeit: die Benutzungsoberäche und Ausgabe sollen gut geordnet und
gegliedert werden, damit man den Hauptinhalt schnell nden kann.
• Angemessener Installations-/Wartungsaufwand: die Installation und Wartung
des Systems sollen nicht so kompliziert und schwer sein.
• Vollständige Dokumentation: wie z.B. Anforderungsdenition, Entwurf, Sourcecode,
Testdokumentation und Installations- und Wartungsunterlagen sind unentbehrliche
Bestandteile eines Projektes.
• Datensicherheit: Umgang mit sicherheitsrelevanten Daten, Sicherheit bei der Datenübertragung,
Erfüllung der Datenschutzaspekte nach niedersächsischem Datenschutzgesetz.
Die Benutzerprolverwaltung wird später teilweise vom Portaldienst
übernommen werden.
173

KAPITEL 15. ANFORDERUNGSDEFINITION
• Barrierefreiheit: Der Dienst soll im Rahmen des Möglichen den Ansprüchen der
Barrierefreiheit gerecht werden.
15.5. Benutzungsoberäche
15.5.1. Allgemeines
Die Bedienung des Systems soll mittels Browser über eine HTML-Oberäche erfolgen.
Dies erfolgt im Kontext des Liferay-Portals. Dabei werden jeweils alle aktuell verfügbaren
Funktionen in der Navigationsbox im linken Bereich des Browserfensters zu sehen sein.
Diese Boxen werden als Portlets im Portal integriert. Funktionen, die vom Benutzer wegen
mangelnder Rechte nicht ausgeführt werden können, werden nicht angezeigt. Dabei wird
es 2 Versionen geben - eine allgemeine Ausführung für Gäste, sowie eine Version mit allen
Funktionalitäten, die für eine vollständige Nutzung der Portlets nötig sind und nur von
eingeloggten Benutzern genutzt werden kann.
Abbildung 15.2.: Gesamtansicht
174

15.5. BENUTZUNGSOBERFLÄCHE
15.5.2. Navigation
Mittels der Navigation ist es dem Benutzer möglich alle Funktionalitäten direkt zu erreichen.
Abbildung 15.3.: Portlet - Navigation
15.5.3. Suche
Die Suche ist die zentrale Schnittstelle und gibt dem Benutzer die Möglichkeit nach Dokumenten
zu suchen. Dabei ist in einfache Suche und erweiterte Suche zu unterscheiden.
einfache Suche
Bei der einfachen Suche ist es dem Benutzer nur möglich zu entscheiden, ob er nur den
lokalen Bestand der Unibibliothek durchsuchen möchte oder global alle an die Suche
angeschlossenen Bibliotheken. Die Gestaltung ist dabei möglichst einfach gehalten, um
dem Benutzer eine intuitive Verwendung zu ermöglichen.
erweiterte Suche
Abbildung 15.4.: Portlet - einfache Suche
Die erweiterte Suche bietet dem Benutzer die eigenständige Anpassung der Suche. Er
hat dabei die Möglichkeit, die gewünschten Dokumenttypen zu wählen, den Suchraum
zu bestimmen sowie eine sehr spezielle Suchanfrage mit mehreren Suchkriterien in verschiedenen
wählbaren Bereichen zu erstellen. Diese Suche richtet sich an Benutzer, die
sich mit der Bibliotheksrecherche auskennen und gezielt nach bestimmten Werken suchen
möchten.
175

KAPITEL 15. ANFORDERUNGSDEFINITION
Abbildung 15.5.: Portlet - erweiterte Suche
15.5.4. Ergebnisausgabe
Die Ergebnisse der Suche werden in einem separaten Portlet dargestellt.
Kurzdarstellung
Die Kurzdarstellung liefert eine kurze Übersicht über die gefundenen Werke. Diese besteht
aus Titel, Autor, Erscheinungsjahr, Dokumenttyp und Status. Der Benutzer kann sich
damit schnell einen Überblick über eine gröÿere Anzahl von Treern verschaen, ohne die
Details jedes Titels genauer ansehen zu müssen.
176

15.5. BENUTZUNGSOBERFLÄCHE
Abbildung 15.6.: Portlet - Ergebnisausgabe
Detaildarstellung
Die Detaildarstellung erscheint nach Klick des Benutzers auf einen Titel in der Kurzdarstellung.
Sie liefert dem Benutzer alle Informationen und Details über dieses Werk, die
im Katalog vorhanden und für ihn von Interesse sind.
177

KAPITEL 15. ANFORDERUNGSDEFINITION
Abbildung 15.7.: Portlet - Ergebnisausgabe mit Details
15.5.5. Benutzerkonto
Das Portlet Benutzerkonto bietet dem Benutzer die Möglichkeit der Anpassung seiner
Daten und Einstellungen. Er kann zum einen seine persönlichen Daten, wie seine Anschrift
oder E-Mailadresse einsehen, wird zur Änderung dieser Daten aber auf das globale
Account-Portlet des Liferay Systems verwiesen. Weiterhin bietet dieses Portlet die Möglichkeit,
eine Voreinstellung der Suchkriterien der erweiterten Suche vorzunehmen, sodass
der Benutzer hier eine persönliche Präferenz auswählen kann, die dann jedes mal bei
Verwendung voreingestellt wird.
178

15.5. BENUTZUNGSOBERFLÄCHE
Abbildung 15.8.: Portlet - Benutzerkonto
Unter Sucheinstellungen hat der Benutzer die Möglichkeit seine Standard-Suchkriterien
zu verändern. Die hier vorgenommenen Einstellungen werden als Vorgabe für die einfache
bzw. erweiterte Suche des Benutzers genommen.
Abbildung 15.9.: Benutzerkonto - Sucheinstellungen
Die Dokumentenübersicht beitet dem Benutzer einen Einlick in seinen aktuellen Bestand
an ausgeliehenen Dokumenten.
179

KAPITEL 15. ANFORDERUNGSDEFINITION
Der Benutzer erhält ausserdem einen Überblich über abgelaufene Ausleihfristen, ggf. fällige
Mahngebüren und kann die für ihn vorgemerkten Dokumente einsehen bzw. Vormerkungen
rückgängig machen (löschen). Desweiteren soll das Verlängern ausgeliehener
Dokumente hier möglich sein.
Abbildung 15.10.: Benutzerkonto - Dokumentenübersicht
Im Abschnitt Weitere Einstellungen kann der Benutzer das Benachrichtigungssystem
des Portals bezüglich des Bibliothessystems kongurieren und soll seine Account-Daten
für eingebundene digitale Bibliotheken verwalten.
Geplant ist das durch eine Schnittstelle zum Message-System des Portals (das es in dieser
Form so noch nicht gibt) Nachrichten z.B. in Form von eMails zu generieren um dem
Benutzer z.B. über fällige Rückgaben von Dokumenten zu Informieren. Hier sind wir in
der Implementierung aber auf die Zusammenarbeit mit dem Entwickler-Team des Benachrichtigungssystems
für Liferay an der Uni Oldenburg angewiesen.
Desweiteren sollen hier Zugangsdaten von den eingebundenen digitalen Bibliotheken abgelegt
werden, um so weit wie möglich eine externe (digitale) Ausleihe zu automatisieren
oder zumindest die entsprechenden Daten vorzuhalten.
180

15.5. BENUTZUNGSOBERFLÄCHE
Abbildung 15.11.: Benutzerkonto - Weitere Einstellungen
15.5.6. mögliche Erweiterungen
Um die Benutzerfreundlichkeit des Bibliotheksdienstes zu verbessern, können weitere sinnvolle
Portlets in das Portal integriert werden. Diese Möglichkeiten stehen nur den angemeldeten
Benutzern zur Verfügung und können individuell hinzugefügt und platziert werden.
Abbildung 15.12.: mögliche Erweiterungsportlets
Eine weitere denkbare Erweiterung wäre die Integration eines Portlets für Lesezeichen.
Der angemeldete Benutzer soll damit die Möglichkeit erhalten sich einzelne Dokumenten
181

KAPITEL 15. ANFORDERUNGSDEFINITION
aus dem Suchergebnis als Lesezeichen zu denieren, so dass er auf diese zu einem späteren
Zeitpunkt direkt zugreifen kann.
Desweiteren können dann einzelne, oder ggf. alle Lesezeichen inclusive der nötigen Metadaten
in ein geeignetes Format (z.B. als .txt, BibTeX oder html-Datei) exportiert und
dem Benutzer zur Weitervearbeitung zur Verfügung gestellt werden.
Abbildung 15.13.: mögliche Erweiterung: Lesezeichen Portlet
15.6. Fehlerverhalten
Fehlerhafte Eingaben und Bedienungsfehler des Benutzers sollen schon im Vorfeld durch
einen einheitlichen Aufbau der Benutzungsoberäche und damit intuitive Bedienung minimiert
werden. Dennoch auftretende Fehleingaben werden direkt abgefangen und der
Benutzer erhält eine aussagekräftige Fehlermeldung, meist mit der Option, die Eingabe
zu wiederholen.
Alle anderen eventuell auftretenden Fehlerfälle (wie z. B. ein Systemabsturz oder fehlende
Datenbankverbindung) werden ebenfalls mit präzisen Fehlermeldungen und entsprechenden
Anweisungen für den konkreten Fehlerfall abgefangen. Soweit möglich, sollen die
Fehler vom Programm selbst behoben werden, z.B. versuchen, die Datenbankverbindung
wieder herzustellen.
Bei kritischen Fehlern soll das System nach Möglichkeit in einem konsistenten Zustand
heruntergefahren werden.
15.7. Dokumentationsanforderungen
Mit dem System muss eine vollständige Dokumentation übergeben werden, die folgende
Dokumente umfasst:
• Anforderungsdenition
• Entwurf
• Sourcecode mit Javadoc
• Implementierungs- und Testdokumentation
182

15.8. AKZEPTANZKRITERIEN
• Installations- und Wartungsunterlagen.
Dabei können die Dokumente natürlich auch in elektronischer Form übergeben werden.
15.8. Akzeptanzkriterien
Das System muss einen einheitlichen Zugri auf die gewählten Bibliothekssysteme bieten
sowie eine entsprechende Verwaltung der anfallenden Daten zu Ausleihe und Benutzerverwaltung.
Wichtig ist weiterhin eine korrekte Integration in die Liferay-Portalumgebung
und gute Interaktion mit den übergreifenden Funktionen des Portals (Themes, benutzerdenierte
Portlets, usw.). Technisch müssen die erstellten Portlets natürlich dem JSR168
Standard entsprechen um auch bei einem Wechsel der Umgebung einwandfrei funktionsfähig
zu bleiben. Die Kriterien werden in einem Abnahmetest geprüft und nach erfolgreichem
Bestehen dieses Tests kann das System freigegeben werden.
183

16. Entwurf
16.1. Einleitung
Der vorliegende Entwurf beschreibt Bibliotheksdienste, die in einem JSR-168-konformen
Web-Portal referenziert werden sollen. Der Hauptanteil liegt hierbei in der Ausarbeitung
einer eektiven Suchfunktion mit einer sinnvollen Präsentation der Suchergebnisse auf
einem Bibliothekskatalog. Dabei liegt der Schwerpunkt in der Integration des Oldenburger
Regionales Bibliotheks- und Informationssystem, kurz ORBIS. Es sollen aber auch
externe Online-Bibliotheken eingebunden werden. Im Vordergrund steht zudem noch die
Entwicklung einer für Benutzer freundliche und innovative Arbeitsumgebung. Die weiteren
Anforderungen an die zu entwickelnden Software sind in der dazugehörigen Anforderungsdenition
beschrieben.
Das Projekt ist integriert in der Entwicklung eines Portals für Studierende der Universität
Oldenburg. Dabei handelt es es sich um ein längerfristig angelegtes, gefördertes
Entwicklungsprojekt mit dem Namen i 3 sic!. In diesem Portal werden die für das Studium
wichtige Prozesse zusammengefasst angeboten. Somit wird dem Student ermöglicht auf
alle wichtigen Informationen und verwaltungstechnischen Dienste zuzugreifen. Das Studierendenportal
ermöglicht es den Benutzern auÿerdem, ihre Benutzungsoberäche an die
eigenen Bedürfnisse anzupassen und so schnell und problemlos alle Dienste zu nutzen, ohne
sich bei jedem Subsystem gesondert authentizieren zu müssen. Weitere Informationen
zum i 3 sic!-Projekt können in dem dazugehörigen Projektbericht nachgelesen werden.
Zur Gestaltung der Bibliotheksdienste werden Portlet-Anwendungen entwickelt, die innerhalb
des Portals verwendet werden können. Durch die Einhaltung des JSR-168 Standard
wird die einwandfreie Funktion der Portlets innerhalb des Lifray-Portals oder bei einem
Wechsel zur einer neuen Umgebung gesichert. Die Umsetzung der Anwendung erfolgt
mit einer J2EE Referenz-Architektur. Zur Ausarbeitung der Applikationslogik werden
Enterprise JavaBeans (EJB) verwendet. JavaServer Pages (JSP) kommen für die Generierung
der Oberäche zum Einsatz. Für den Zugri auf die projektinterne Datenhaltung
wird Hibernate als Persistenz-Framework eingesetzt. Durch den starken Einsatz der Java-
Technologien wird die Software einfach skalierbar und mit geringem Aufwand wart- und
erweiterbar.
Als Basistechnologien (-themen) werden für den Entwurf von der Projektgruppe erarbeitet
bzw. verwendet:
• Web-Technologien: Verwendung von Portalen, WebServices und Applicationsservern
• Informationssysteme: Content-Management und bibliographische Metadaten
• Bibliotheksdienste: Einarbeitung in Recherchemethoden
Der Entwurf wurde entwickelt, indem die Projektgruppe intern für je einen spezischen
184

16.2. ARCHITEKTUR
Bereich aufgeteilt wurde. So entstanden vier Untergruppen für die nachfolgend genannten
Bereiche. Diese Aufteilung dient ebenfalls zur Weiterentwicklung des Projekts.
• Benutzerkonto: Verwaltung der Einstellungen des Benutzers
• Mediator/Wrapper: Kommunikation mit den verschiedenen Bibliothekssystemen
• Logik: Gestaltung der Suchfunktion, Entwicklung der Kommunikation zwischen
Suche und Mediator
• GUI: Gestaltung der Benutzungsoberäche
In diesem Entwurfsdokument wird die Umsetzung des Projektauftrages beschrieben. Im
ersten Kapitel wird die Architektur der Software dargestellt. Diese gibt einen Überblick
des Anwendungsdesigns und dessen Schichten wieder, wobei die einzelnen Schichtelemente
in den darauf folgenden Kapitel durch Klassenbeschreibungen und Sequenzdiagrammen
vertieft werden. Die Interaktion zwischen den Komponenten der Software werden
im Architektur-Kapitel ebenfalls durch Sequenzdiagrammen und weitere Beschreibungen
vertieft. Die beiden nächsten Kapitel präsentieren mit der Suchlogik und dem Mediator/Wrapper
den zentralen Bereich dieses Projektes. In diesem Bereich werden die
Hauptaufgaben der Software, nämlich die Suche innerhalb der verschiedenen Bibliothekskatalogen,
vollzogen. In dem Benutzerkonto, das in dem darauf folgenden Konto dargestellt
wird, kann man Randbedingungen der Suche oder weitere Informationen einsehen
und teilweise bestimmen. Das Kapitel Benutzungsoberäche präsentiert die Arbeitsäche
für den Anwender der Software. Die GUI stellt alle Funktionen der vorher beschriebenen
Komponenten dem Benutzer zu Verfügung. Die für den Betrieb der Anwendung benötigte
Datenbank wird im vorletzten Kapitel dargestellt. Schlieÿlich endet das Dokument mit
der Beschreibung der Vorgehensweise beim Testen. Abgerundet wird dieses Entwurfsdokument
durch das Glossar. In ihm werden viele technische Begrie mit weiterführenden
Referenzen erklärt.
16.2. Architektur
16.2.1. Technologiewahl
Für die Umsetzung der denierten Anforderungen werden nun zunächst die Technologien
betreenden Entwurfsentscheidungen erläutert.
Anbindung externer Bibliotheksdienste
Um den Anforderungen sowohl bezüglich des Antwortverhaltens als auch der Erweiterbarkeit
des Systems gerecht zu werden, wird der Zugri auf die angebundenen externen
Bibliotheksdienste in sog. Wrappern gekapselt, die in der Lage sind, parallel zueinander
Anfragen an die verschiedenen Quellen zu stellen.
Da Parallelität in der Entwicklung von Informationssystemen der vorliegenden Gröÿenordnung
grundsätzlich eine äuÿerst anspruchsvolle Aufgabe darstellt und erfahrungsgemäÿ
häug Quelle von schwer zu reproduzierendem Fehlverhalten ist, werden diese Wrapper
als standardisierte Softwarekomponenten Message Drive Beans (MDBs) umgesetzt,
185

KAPITEL 16. ENTWURF
die ihrerseits auf das standardisierte Java Message Service (JMS) API zurückgreifen. Auf
die für MDBs notwendige Laufzeitumgebung, den Applikationsserver, wird weiter unten
näher eingegangen.
Datenhaltungsschicht
Neben den für alle auch nicht authentizierte Benutzer zugänglichen Möglichkeiten
zur Suche sind auch diverse Funktionalitäten umzusetzen, die nach erfolgreicher Authentizierung
das Ablegen von projektspezischen Daten erfordern, etwa die Such-Historie
oder auch Funktionalitäten aus den denierten Anwendungsfällen des Benutzerkontos.
Für diese Datenhaltung wird das relationale DBMS MySQL gewählt. Zu den Vorteilen
dieses Systems gehören seine Lizenzkostenfreiheit und Quelloenheit. Zudem wird es aufgrund
seiner Popularität ständig verbessert und weiterentwickelt, so dass es zum Zeitpunkt
dieser Arbeit bereits über einen relativ breiten Funktionalitätsumfang verfügt. Dieser ist
zwar nicht vergleichbar mit dem von Systemen wie etwa dem Oracle Database Server,
reicht aber aller Einschätzung nach für die vorliegenden Anforderungen aus.
Auÿerdem wird durch den Einsatz von Hibernate, auf den weiter unten näher eingegangen
wird, ein hoher Grad an Unabhängigkeit vom unterstützten SQL-Sprachschatz des verwendeten
DBMS erreicht. Bei wachsendem Funktionalitätsumfang des Bibliotheksdienstes
und damit möglicherweise verbundenen erhöhten Anforderungen an das zugrunde liegende
DBMS sollte ein Wechsel auf ein mächtigeres System also relativ problemlos möglich
sein.
Der Zugri auf das MySQL-DBMS vom J2EE-Applikationsserver aus erfolgt über die Java
Database Connectivity (JDBC) API. Die Implementierung dieser Schnittstelle für MySQL
trägt den Namen Connector/J und unterstützt in der gewählten Version 3.1.12 den JDBC
3.0 Standard. Die Operabilität mit JBoss und insbesondere Hibernate gilt mittlerweile
als erprobt.
Geschäftslogik
Applikationsserver JBoss
Die Wahl des J2EE-Applikationsservers el bereits im Vorfeld der Arbeit dieser Projektgruppe
auf JBoss, weshalb dies auch keine Entwurfsentscheidung dieser Projektgruppe
darstellt und bereits in der Anforderungsdenition festgehalten wurde. Als entscheidendes
Kriterium für JBoss kann dessen Quelloenheit gesehen werden. Neben JBoss existiert
zum Zeitpunkt dieses Projekts mit JOnAS lediglich ein weiterer J2EE-zertizierter Open-
Source Applikationsserver, der allerdings noch nicht über eine so groÿe Verbreitung und
Bedeutung in der Wirtschaft verfügt wie JBoss.
Hibernate
Durch den bereits erwähnten Einsatz des Persistenz-Frameworks Hibernate wird ein gänzlich
objektorientierter Entwurf des Datenmodells ermöglicht. So kann auf einen Datenbankentwurf
im rein relationalen Sinne mit einer in Data Denition Language (DDL)
mündenden Spezikation des Datenmodells weitestgehend verzichtet werden.
Schnittstellen
Die Erzeugung der EJB-Interfaces (home interface, local home interface, remote interface
und local interface) kann bei der Entwicklung semi-automatisch durch Werkzeugunterstützung
geschehen. Die Session Beans können daher sowohl für den Remote-Zugri ausgelegt
186

16.2. ARCHITEKTUR
werden als auch für den Zugri von innerhalb der selben Virtual Machine mit höherer
Performanz.
Da allerdings im Kontext dieses Projekt nicht von einer physikalisch verteilten Architektur
ausgegangen werden muss, werden die Session-Beans hier lediglich mit den lokalen
Interfaces ausgestattet. Erweiterbarkeit ist diesbezüglich mit sehr geringem Aufwand gegeben.
Präsentationsschicht
Serverseitige Präsentation
Die Präsentation von Daten und Funktionalität geschieht durch ein serverseitig generiertes
Web-Frontend nach JSR-168. Integriert in den Applikationsserver JBoss steht hierfür das
Portal Liferay in Kombination mit dem Web-Container Tomcat zur Verfügung. Tomcat
ist der am weitesten verbreitete Container für Servlets und JSPs und wird als ozielle
Referenz-Implementierung dieser Spezikationen im Java Community Process (JCP)
benutzt.
Um eine hohe Lesbarkeit des Codes zur Seitengenerierung und damit verbunden die Einhaltung
des Separation of Concerns Prinzips zu gewährleisten, wird auf JSP-Scriptlets
weitestgehend verzichtet und die Ausgabe stattdessen mittels Custom-Tags realisiert. Dazu
wird auf die ebenfalls im JCP als Referenz-Implementierung entwickelte JSP Standard
Tag Library (JSTL) zurückgegrien.
Clientseitig
Aufgrund der Einbettung des Projekts in das Portal müssen weitreichende Einschränkungen
in Sachen Barrierefreiheit in Kauf genommen werden. So ist etwa der Zugri auf
das Portal und damit auch auf den Bibliotheksdienst dieses Projekts nur mit clientseitig
aktiviertem Javascript möglich. Auch werden WAI-Richtlinien kaum konsequent
befolgt und das generierte Markup entspricht bei strenger Auslegung keinem des W3C
spezizierten Dokumententyps. Diese Vorgaben sind durch die Projektgruppe nicht zu beeinuÿen.
Die resultierenden Eigenschaften des Bibliotheksdienstes werden daher nicht an
formalen Spezikationen dieser Art gemessen, sondern an ihrer praktischen Operabilität
in gängigen Browsern und den üblicherweise clientseitig verfügbaren Technologien.
187

KAPITEL 16. ENTWURF
16.2.2. Umzusetzende Anwendungs-Architektur
Internet
Clientseitige
Präsentationsschicht (GUI)
PG-Bibliotheksportalsystem
HTTP
Portlets
JSPs
Serverseitige
Präsentationsschicht
Geschäftslogik
Geschäftslogikschicht
Hibernate
Wrapper
Mediator
Wrapper
Datenzugriffsschicht
JDBC
(Connector/J)
URICA
Schnittstelle
OAI Protocol
for Metadata
Harvesting
JNDI /
RMI-IIOP
JNDI /
RMI-IIOP
JNDI /
RMI-IIOP
JNDI /
RMI-IIOP
MySQL
Datenbank
URICA
CiteSeer
Datenhaltungsschicht
Abbildung 16.1.: Grobarchitektur des Bibliotheksdienstes, schichtenorientierte Sicht
188

16.2. ARCHITEKTUR
Abbildung 16.1 stellt den Architekturentwurf der Bibliotheksdienstes dar und deutet dabei
mit URICA und CiteSeer zwei angebundene externe Bibliothekssysteme als Datenquellen
an.
Diese Architektur beinhaltet grundsätzlich drei abgekapselte Schichten und entspricht dem
Model-View-Controller (MVC) Entwurfsmuster. Dabei übernimmt die Client-Schicht ausschlieÿlich
Aspekte der Darstellung von Daten und Funktionalität (thin client). Von
hier aus erfolgen Aufrufe an den darunter liegenden Applikationsserver, dessen EJB-
Komponenten ihrerseits auf die angebundenen externen Systeme sowie auf eine Datenbank
zugreifen, die für die Persistenz der Applikationsdaten sorgt.
Die Schichtenbegrie, nach denen die weitere Entwurfsdokumentation gegliedert ist und
die so auch bereits im vorigen Abschnitt zur Technologiewahl verwendet wurden seien
hier wie folgt deniert:
• Die Datenhaltungsschicht bilden zum Einen die externen Bibliothekssysteme und
zum Anderen das zugrundeliegende DBMS MySQL.
• Als Schicht der Geschäftslogik werden die EJB-Komponenten (Session Beans,
Message Driven Beans sowie assoziierte Hilfs- und Persistenzklassen) bezeichnet. Sie
laufen im Kontext des EJB-Containers des JBoss Applikationsservers.
• Die Präsentationsschicht gliedert sich in serverseitige und clientseitige Präsentation,
wobei die Entwicklungsarbeit sich weitestgehend auf den serverseitigen Anteil,
d. h. die im Portlet-Container des JBoss Applikationsservers laufenden Portlets und
deren JSPs konzentriert.
Der Applikationsserver vereint sowohl die beiden Aspekte Datenzugri und Bedienung
von Nutzeranfragen der Geschäftslogik als auch die serverseitige Präsentation.
Abbildung 16.2 stellt eine kommentierte, komponentenorientierte Sicht auf die Architektur
dar.
189

KAPITEL 16. ENTWURF
Abbildung 16.2.: Grobarchitektur des Bibliotheksdienstes, komponentenorientierte Sicht
190

16.2. ARCHITEKTUR
Kommunikationspartner
In den folgenden drei Sequenzdiagrammen wird der Informationsaustausch zwischen den
beteiligten Komponenten bei einer typischen Suche dargestellt. Die Sequenzdiagramme
sind durch Interaktionsreferenzen geschachtelt. Eine Suche wird durch einen Benutzer
angestossen, der die gewünschten Suchparameter im GUI eingibt. Die Suchparameter
werden an die serverseitige Geschäftslogik weitergegeben und das Ergebnis der Suche
wird dem Benutzer wieder im GUI angezeigt (Abbildung 16.3).
Abbildung 16.3.: Sequenzdiagramm für das gesamte System
Die serverseitigen Komponenten bestehen aus EJBs für die Suchlogik, den Mediator und
die Wrapper. In der SearchBean werden die Benutzereingaben überprüft und aus den
überprüften Parametern wird ein Search-Objekt erstellt. Dieses Search-Objekt wird an
den Mediator übergeben und als Ergebnis-Objekt wird ein SearchResultSet erwartet. Die
Hauptaufgabe der Suchlogik ist das Sortieren und Bewerten der gefundenen Ergebnisse.
Nach dem Sortieren wird das Ergebnis-Objekt noch im Benutzerkonto gespeichert und
dadurch die Suchhistorie festgehalten (Abbildung 16.4).
191

KAPITEL 16. ENTWURF
Abbildung 16.4.: Sequenzdiagramm EJB-Schicht
Der Mediator entnimmt dem Search-Objekt, auf welchen Datenquellen die Suche durchgeführt
werden soll, und schickt eine Nachricht an die entsprechenden Wrapper. Die Suche
auf den verschiedenen Datenbeständen erfolgt dann asynchron. Nachdem der Mediator
die Suche gestartet hat, wartet er auf Ergebnisse. Wenn die Wrapper in einer denierten
Zeitspanne keine Ergebnisse liefern, werden diese verworfen. Die gefundenen Ergebnisse
werden alle in ein Ergebnis-Objekt verpackt (Abbildung 16.5).
192

16.2. ARCHITEKTUR
Abbildung 16.5.: Sequenzdiagramm Mediator und Wrapper
193

KAPITEL 16. ENTWURF
Packaging
Die Gesamtheit der Java-Klassen und -Interfaces des Systems wird nach strukturellen
Gesichtspunkten auf Pakete aufgeteilt. Die entworfene Paketstruktur lässt sich Abbildung
16.6 entnehmen. Auf die einzelnen Pakete wird in den folgenden Abschnitten zum Entwurf
der einzelnen Anwendungs-Schichten des Öfteren Bezug genommen.
Abbildung 16.6.: Paketdiagramm
194

16.3. SUCHLOGIK
16.3. Suchlogik
Das folgende Kapitel setzt sich mit den Grundlagen und dem Entwurf der Suchlogik auseinander.
Dabei wird zunächst in Abschnitt 16.3.1 auf eine grundsätzliche Klärung der
Aufgabe eingegangen, wo neben einigen einführenden Worten zu Suchfunktionen an sich
auch die in diesem Projekt konkreten Arbeitsfelder abgesteckt werden und eine Einordnung
in das Gesamtsystem vorgenommen wird. Erst jetzt werden in Abschnitt 16.3.2 die
Technologien und Modelle angesprochen, die zur Realisierung der Suchfunktion vorgesehen
sind. Im Anschluss daran folgt im Abschnitt 16.3.3 eine kurze Beschreibung der
Klassen und Methoden der zu entwickelnden Logikkomponente, die in Abschnitt 16.3.4
um eine abschlieÿende Dynamikbeschreibung ergänzt wird.
16.3.1. Aufgabe
Die Suchfunktion stellt eine elementare wenn nicht sogar die wichtigste Funktion
innerhalb eines Bibliotheksdienstes dar. In einfachen Worten dient sie zur Lösung der
Aufgabe, bestimmte Dokumente aus einer grossen Anzahl von Dokumenten verschiedenen
Typs anhand von Suchparametern zu nden. Jedoch steckt hinter dieser Aufgabe eine
Vielzahl an kleinen Teilaufgaben und ein hohes Maÿ an Komplexität, das davon abhängig
ist, wie genau und wie intelligent die Suche nach Dokumenten ablaufen soll.
Der generelle Ablauf einer Suche verläuft in den folgenden Schritten: Zuerst legt der Suchende
Suchkriterien und ggf. weitere Parameter fest, die eine Einussnahme auf die Suche
oder das Suchverfahren selbst erlauben. Nach diesem Schritt wird der zu durchsuchende
Datenbestand mit den angegebenen Suchkriterien verglichen, wobei unterschiedliche Methoden
zum Einsatz kommen können. Abschliessend werden dem Suchenden im letzten
Schritt die Ergebnisse präsentiert im besten Fall geordnet nach Relevanz oder anderen
Kriterien [WCc].
Die Güte einer Suchfunktion ist abhängig davon, wie intelligent die eingesetzten Verfahren
sind. Ein Maÿ für Intelligenz im Kontext dieser Funktion ist z. B. das Verhältnis
zwischen dem Aufwand, den man bei der Angabe von Suchkriterien investiert, und der
dabei erzielten Treergenauigkeit innerhalb einer annehmbaren Suchdauer. Dabei gilt es,
den bestmöglichen Bezug zu den Suchkriterien zu ermitteln, um dem Suchenden möglichst
genau die Ergebnisse anzubieten, die er benötigt. Dazu sind Sortierungen nach Relevanz,
die Einbeziehung von möglichen Eingabefehlern und Rankings nach Treergenauigkeit
und -häugkeit unumgänglich.
Aufgrund der Komplexität, die hinter einer solchen Suchfunktion steckt, wird die komplette
Logik in einer eigenständigen Komponente gekapselt. Diese Komponente wird, wie
schon im Kapitel über den Entwurf diskutiert, als eine Enterprise JavaBean (EJB)
genauer als SessionBean realisiert. Diese ist im Architekturmodell in der Geschäftslogikschicht
angesiedelt und muss daher über wohl denierte Schnittstellen sowohl nach
oben mit den Portlets der Präsentationsschicht als auch nach unten mit dem Mediator
in der Datenzugrisschicht kommunizieren. Hinzu kommt die Zusammenarbeit mit der
SessionBean, die für das Benutzerkonto zuständig ist und auf gleicher Ebene in der Geschäftslogikschicht
angeordnet ist(vgl. Abbildung 16.1).
Zur Durchführung einer Suche werden von der GUI-Schicht die relevanten Parameter
übergeben. Diese lassen sich in Suchkriterien auf der einen Seite und Suchparameter, zur
externen Einussnahme auf den Suchablauf und die Ergebnisdarstellung, auf der anderen
195

KAPITEL 16. ENTWURF
Seite klassizieren. Diese Parameter werden nach einer Prüfung in Bezug auf Korrektheit
und Sinnhaftigkeit es soll u.a. kein HTML-Code als Parameter verwendet werden
können in einem Suchobjekt gekapselt und an den Mediator der Datenzugrisschicht
übergeben. Dieser initiiert nun die eigentliche Suche an den angebundenen Datenquellen
und gibt die Suchergebnisse in Form eines Resultobjektes an die Logik-Instanz der
Suche zurück. Erst jetzt beginnt die eigentliche Arbeit der Suchlogik. Die empfangenen
Suchergebnisse müssen entsprechend der Suchparameter sortiert werden und zudem nach
Relevanz und Treergenauigkeit gewichtet werden. Techniken zur Ermittlung von Relevanz
werden im folgenden Unterkapitel diskutiert. Sind die Suchergebnisse in dieser Form
bearbeitet, können sie zurück an die GUI-Schicht also das Portlet, das die entsprechende
Anfrage gestellt hat übergeben werden, wo sie grasch aufbereitet angezeigt werden
können.
Zusätzlich zur reinen Darstellung sollen die Suchergebnisse auch noch in einer Datenbank
abgelegt werden, um auf diese Weise eine Suchhistory anbieten zu können. Zu diesem
Zweck werden also die Ergebnisse auch an das Benutzerkonto übergeben, das diese Daten
in serialisierter Form als BLOB neben einigen eindeutigen die Suchanfrage charakterisierenden
Parametern in einer Datenbank abspeichert.
16.3.2. Technologien und Modelle
Der folgende Abschnitt behandelt die Technologien und Modelle, die hinter einer komplexeren
Suchfunktion stecken, wie sie innerhalb dieses Projekts realisiert werden soll.
Dabei gliedert er sich in zwei Bereiche. Der erste führt in die Thematik des Rankings von
Suchergebnissen und deren Relevanzbestimmung ein. Im zweiten Bereich wird dann auf
Methoden und konkrete Verfahren der fehlertoleranten Suche eingegangen.
Ranking und Relevanz
Als Ranking (oder auch Rangliste) wird allgemein das Ergebnis einer Sortierung von mehreren
vergleichbaren Objekten verstanden, die nach verschiedenen Kriterien bewertet worden
sind [WCb]. Sinn und Zweck eines solchen Rankings im Kontext der zu entwickelnden
Suchfunktion besteht darin, die möglicherweise zahlreichen Suchergebnisse anhand ausgewählter
Kriterien zu bewerten, um somit dem Suchenden eine nach Relevanz absteigende
Liste von Ergebnissen präsentieren zu können. Auf diese Weise ndet er im Idealfall die
am besten passenden Treer der Suche am Anfang der Ergebnisliste.
Problematisch ist allerdings, dass das zu entwickelnde System keine Suche auf einem eigenen
Datenbestand durchführt, sondern viele heterogene Datenquellen über unterschiedliche
Schnittstellen und Wrapper einbindet und dem Suchenden eine globale Suche über
diese Quellen anbietet. Somit kann an dieser Stelle nur sehr beschränkt auf eine Relevanzbestimmung
oder gar auf fehlertolerantes Suchen Einuss genommen werden, da die
Suchanfrage in Form eines Suchobjektes lediglich an den Mediator übergeben wird, der
dieses dann wiederum an alle benötigten Wrapper weiterleitet. Aus diesem Grund kann
zum Beispiel auf Tipp- oder Rechtschreibfehler nicht in der Form reagiert werden, wie
es möglich wäre, wenn man selbst auf den Datenbeständen suchen würde. Weiterhin ist
davon auszugehen, dass jede der angebundenen Datenquellen andere Relevanzmodelle
oder Rankingprinzipien verwendet, genauso wie einige vielleicht fehlertolerante Suchen in
hohem Maÿe unterstützen und andere wiederum gar nicht.
196

16.3. SUCHLOGIK
Das für den Bibliotheksdienst angestrebte Relevanzmodell muss also mit den zusammengeführten
Ergebnissen aller angebundenen Datenquellen arbeiten, die vom Mediator in bereinigter
Form an die Suchlogik übergeben werden. D.h. es werden die gesammelten Suchergebnisse
als Grundlage genommen und anhand verschiedener Kriterien und einem komplizierten
Schlüssel bewertet. Als Vorbild soll hier u.a. Google dienen (www.google.de),
wo Anzahl der Vorkommen, Nähe und Verteilung der Suchbegrie u. a. als Grundlage für
das Ranking genommen werden. Weiterhin sollen Verfahren aus dem Bereich der fehlertoleranten
Suche (siehe Abschnitt 16.3.2) angewendet werden, um die Treergenauigkeit
beziern zu können. Insgesamt soll so jedem Suchergebnis eine Prozentzahl zugewiesen
werden, die angibt, inwieweit dieses Ergebnis der Suchanfrage genügt.
Neben dem Ranking nach dem Kriterium der Relevanz hat der Suchende zusätzlich die
Möglichkeit, die Suchergebnisse nach verschiedenen Suchkriterien wie z.B. Titel oder
Erscheinungsjahr sowohl auf- als auch absteigend sortieren zu lassen.
Fehlertolerantes Suchen
Die Methoden des fehlertoleranten Suchens zielen darauf ab, fehlerhafte Eingaben als
solche zu erkennen und die Suche normal durchzuführen. Dabei werden die fehlerhaften
Eingaben nach Möglichkeit auf korrekte abgebildet und die Suche mit den korrekten
Eingaben weitergeführt. Auf diese Weise können dem Suchenden z. B. auch alternative
Suchbegrie vorgeschlagen werden, wenn die Suche nur wenige oder keine Ergebnisse
liefern konnte. Fehlerhafte Eingaben werden dabei in zwei Kategorien eingeteilt. Auf der
einen Seite die Tippfehler, die entstehen, wenn der Suchende aus Versehen eine oder
mehrere falsche Tasten betätig, und auf der anderen Seite die Rechtsschreibfehler, die
zustande kommen, wenn der Suchende nicht weiss, wie das Suchwort geschrieben wird
[Fri96].
Um eine solche fehlertolerante Suche zu ermöglichen, ist es nötig, den Unterschied zwischen
den zu vergleichenden Zeichenketten durch Konvertierungen zu eliminieren und somit
einen Test auf Identität möglich zu machen. Verfahren dieser Art bezeichnet man als
sprachorientierte Verfahren. Alternativ kann ein Fehlerabstand deniert werden, der nach
dem Wortvergleich eine Kennzahl über die Grösse der Abweichung liefert. Diesem Prinzip
folgen die buchstabenorientierten Verfahren.
Der Einsatz von sprachorientierten Verfahren kann sehr leicht helfen, dem Problem der
Rechtschreibfehler zu begegnen, was in der grundlegenden Idee dieser Verfahren begründet
ist. Das Prinzip ist darauf ausgerichtet, Ausdrücke zu nden, die zwar anders geschrieben,
aber dennoch gleich oder zumindest ähnlich ausgesprochen werden. Es kann also erwartet
werden, dass bei einer Suche nach der Zeichenkette Meyer auch die Zeichenkette Mayer
in die Suche mit einbezogen wird. Aus diesem Grund werden diese Suchverfahren auch
phonetische Suchen genannt [RS77]. Allerdings kann eine Implementierung der phonetischen
Suche lediglich Erkenntnisse einer Sprache optimal nutzen, was in der Natur des
Prinzips begründet ist. Daher sind diese Methoden für internationale Anwendungen nur
bedingt geeignet. Verfahren, die dieses Prinzip umsetzen, sind z.B. das Soundex Verfahren
(siehe [Knu73]) oder die phonetische Codierung.
Die buchstabenorientierten Verfahren denieren ein Maÿ für Fehlerabstände zwischen zwei
Zeichenketten, das insbesondere zur Identizierung von Tippfehlern wie Buchstabendreher
oder das Drücken einer falschen Taste herangezogen werden kann. Bekanntester Vertreter
der Verfahren dieser Art ist die Levenshtein-Distanz (auch Editierdistanz) (siehe [Lev66]).
197

KAPITEL 16. ENTWURF
Sie ist deniert als ein Maÿ für den Unterschied zwischen zwei Zeichenketten bezüglich
der minimalen Anzahl der Operationen Einfügen, Löschen und Ersetzen von einzelnen
Zeichen, um eine Zeichenkette in eine andere zu überführen. Dieses Verfahren besitzt
zahlreiche Varianten und Erweiterungen in Bezug auf die Gewichtung und die Anzahl der
oben genannten Operationen [Fri96].
Wie schon im vorherigen Unterkapitel angesprochen, kann eine fehlertolerante Suche im
eigentlichen Sinne aus den genannten Gründen innerhalb dieses Projektes nicht angewendet
werden. Allerdings werden zahlreiche dieser Verfahren und Methoden implementiert,
um die vom Mediator erhaltenden Suchergebnisse zu gewichten und ein Ranking nach
Relevanz zu ermöglichen.
16.3.3. Klassenbeschreibung
Die Klassenbeschreibung der Suchlogik beschränkt sich wie schon angesprochen auf eine
EJB genauer gesagt eine Stateless SessionBean. Diese EJB kommuniziert mit den
Suchportlets, der Mediator-EJB und der Benutzerkonto-EJB. Neben den obligatorischen
Methoden einer EJB, die den Lifecycle regeln, stellt die Businessmethode search() die
zentrale Methode dieser Komponente dar. Sie wird von der Präsentationsschicht aus aufgerufen,
erledigt alle die Suche betreenden Aufgaben und übergibt das Resultat wieder
an das aufrufende Portlet. Da die Suche und die Generierung der Suchergebnisliste, wie
in den vorherigen Unterkapiteln angesprochen, sehr komplex sind, werden Teilaufgaben
in separate Methoden ausgegliedert:
Methode
checkParam(Parameter)
createSearchObject(Parameter)
calcRelevance(Result)
sort(ResultSet, Mode)
Parame-
saveSearch(ResultSet,
ter)
Funktionalität
Überprüft die Eingaben des Benutzers auf Fehler
Erstellen eines Suchobjektes und füllen des Suchobjektes
mit den übergebenen Parametern
Berechnung der Relevanz eines Ergebnisses
Durchführung der eigentlichen Sortierung der Ergebnismenge
nach dem angegebenen Kriterium
(Relevanz, Titel, Datum,...)
Übergabe des Suchergebnisses an das Benutzerkonto
unter Angabe der Suchparameter
Tabelle 16.1.: Klasse SearchBean
Das Klassendiagramm (Abbildung 16.7) zeigt die Methoden der Komponente SearchBean
und verdeutlicht die Abhängigkeit zu anderen Klassen. Die Session-Bean unterstützt den
Local-Client-View durch das Remote-Home-Interface LocalSearch und das Local-Home-
Interface LocalSearchHome. Über die Klasse org.pgportal.ejb.util.EjbLocalHomeFactory
bekommt die SearchBean Zugri auf die beiden Session-Beans MediatorBean und UserAccountBean.
Die MediatorBean ist dabei für die Durchführung der Suche zuständig und
mit der UserAccountBean wird die Suchhistorie festgehalten. Auÿerdem verwendet die
SearchBean noch die Klassen SearchResultSet, SearchObject und InternetRessource aus
dem Package org.pgportal.ejb.dto zur Datenhaltung.
198

16.3. SUCHLOGIK
Abbildung 16.7.: Klassendiagramm der Suchlogik
199

KAPITEL 16. ENTWURF
16.3.4. Dynamikbeschreibung
Die Suchlogik ist in der Komponente SearchBean implementiert. Zuerst werden die Benutzereingaben
auf Fehler überprüft. Die validierten Benutzereingaben werden dann verwendet,
um ein Search-Objekt anzulegen. Dieses Search-Objekt wird an den Mediator übergeben,
der als Ergebnismenge ein SearchResultSet liefert. Die Hauptaufgabe der Suchlogik
besteht darin, die Ergebnismenge zu sortieren. Die einzelnen Ergebnisse werden
anhand verschiedener Kriterien einem Ranking unterzogen. Die sortierte Ergebnismenge
wird dann zusammen mit den Suchparametern im Benutzerkonto als Suchhistorie gespeichert
(Abbildung 16.8).
Abbildung 16.8.: Sequenzdiagramm der Suchlogik
16.4. Mediator / Wrapper
Der Mediator ist die zentrale Schnittstelle zu den angebundenen Quellen, hier kann die
Suchlogik z.B. eine Suche (einmalig) anstossen, die dann parallel über mehrere Quellen
(digitale Bibliotheken) durchgeführt wird.
200

16.4. MEDIATOR / WRAPPER
16.4.1. Aufgabe
Aufgabe des Mediators ist es, der Suchlogik eine einheitliche Sicht auf die verschiedenenartigen
angesprochenen Bibliotheken zu bieten. Der Mediator spricht Wrapper an, die die
unterschiedlichen Bibliotheksschnittstellen kapseln. Die Wrapper führen die eigentliche
Anfrage an die Ressourcen durch, transformieren die Ergebnisse in die anwendungsspezische
Datenstruktur und stellen sie dem Mediator bereit. Dieser führt die erhaltenen
Resultate aller Wrapper (unter Eliminierung von Duplikaten) zusammen und gibt sie
wieder zurück an die Logik.
Desweiteren bietet der Mediator den Zugri auf das ORBIS-Benutzerkonto vom Portal
aus. Hier handelt es sich um eine Schnittstelle zum URICA-System der Uni-Oldenburg,
mit der das Benutzerkonto-Portlet in der Lage sein wird, eine Übersicht über die aktuell
vom Benutzer ausgeliehenen Dokumente und vor allem seine Leihfristen einzusehen.
Vorgesehen ist auch, dies mit einer Übersicht über bereits angefallene oder drohende
Mahngebüren zu vereinen (vgl. Abbildung 16.31).
Ausserdem wird es über diese Schnittstelle möglich sein, Dokumente für die Ausleihe
vorzumerken bzw. bestehende Vormerkungen aufzuheben.
16.4.2. Die verschiedenen Quellen
Grundlage der Wrapper-Struktur soll zunächst ein gleichwertiges Parallelsystem zum bestehenden
ORBIS Online-Katalogsystem sein. Weiterhin soll die Software aber auch um
zusätzliche Quellen für Dokumente erweiterbar sein.
Vorgesehen ist für das Endprodukt eine Anbindung an zumindest folgende Systeme:
BIS-Oldenburg:
Das BIS-Oldenburg wird über das bestehende URICA-System angebunden. Hier stellt
uns das URICA-System unterschiedliche Suchräume zur Verfügung, so dass wir die Suche
auch auf Teilmengen des Gesamtkataloges (wie zum Beispiel eine Suche nur über den
Bestand des Standortes Wechloy) ermöglichen können. Als Schnittstelle zur Datenübergabe
vom URICA-System ist bereits eine MAB1 basierte Wrapper-Implementierung im
(experimentiellen) Einsatz. Zukünftig wird diese (primitive) Anbindung allerdings durch
eine XML-basierte Schnittstelle, die das SRU/SRW Protokoll nutzt, ersetzt werden.
GBV:
Der GBV ermöglicht eine Abfrage seiner Datenbanken über das Z39.50 -Protokoll. Für
diese Schnittstelle ist bisher noch kein Wrapper verfügbar bzw. implementiert.
CiteSeer:
CiteSeer stellt eine Datenbank zur Verfügung, die sich primär mit Texten aus dem Bereich
Informatik befasst. Alle hier inidzierten Dokumente sind online zum sofortigen Download
verfügbar. Da CiteSeer die automatisierte Abfrage der eigenen Datenbank nur über das
OAI -Protokoll ermöglicht, welches keine Suche, sondern nur eine sequentielle Abfrage ermöglicht,
muss der entsprechende Index lokal in einer Datenbank repliziert werden, auf
welcher dann der entsprechende Wrapper seine Suchanfrage per SQL-Queries ausführt.
Das Aktualisieren der lokalen Datenbank wird über ein externes Programm (dieses implementiert
das OAI Protokoll) auf zeitgesteuerter Basis durchgeführt.
CiteSeer wurde hierbei auf allgemeinen Beschluss hin als erste Quelle auf OAI Basis gewählt.
Sobald der Wrapper vollständig fertiggestellt ist, lässt sich dieser mit sehr geringem
Aufwand für jede beliebige OAI-Quelle anpassen und ermöglicht somit die Anbindung an
201

KAPITEL 16. ENTWURF
eine sehr groÿe Zahl von Quellen mit digital verfügbaren Dokumenten.
16.4.3. Entwicklungsgeschichte
Die Anbindung an das Softwaresystem des BIS Oldenburg erfolgt über das URICA-
System. URICA stellt dabei verschiede Möglichkeiten der Abfrage zur Verfügung. Zu
Beginn des Projektes war der erste Wrapper, der eine Anbindung an das URICA-System
zur Verfügung stellte, auf das MAB1 -Datenformat ausgerichtet. Im Laufe der Entwickung
und vor allem durch Korrespondenz mit Vertretern des BIS wurde allerdings deutlich, dass
MAB1 zum einen recht schwierig automatisch zu verarbeiten ist und es zum anderen ein
recht altes Format ist, dem heute mehrere (moderne) als Konkurrenz gegenüberstehen.
Nach einer weiteren Evaluierung wurde deshalb beschlossen, diesen Wrapper zu entfernen
und eine Anbindung an URICA über das moderenere SRU/SRW Protokoll zur Verfügung
zu stellen, welches die erforderlichen Daten in einer XML-Form zurück gibt. Der
entsprechende SRU-Wrapper ist somit der für die URICA-Anbindung relevante und wird
deshalb im weiteren als einziger hier näher erläutert.
16.4.4. Technologien und Modelle
Damit der Mediator eine einheitliche Schnittstelle zwischen der Suchlogik und den angebundenen
Quellen realisieren kann, wird eine Reihe von Datentransferobjekten benötigt,
die anwendungsglobal diese Schnittstellen festlegen. Der Mediator kapselt durch die Wrapper
alle Anfragen sowie die entsprechenden Suchergebnisse in ein anwendungsspezisches
Format, bestehend aus einigen wenigen Datenobjekten:
Anfrage-Objekte
Zur Anfrage einer Suche an den Mediator wurde folgende Datenstruktur gewählt:
SearchObject
Hier werden alle Daten, die zur Denition einer Suche benötigt werden, per get/set gesetzt
und ausgelesen. Dies betrit die Art der Suche (nach Autor, Titel o.Ä.), eine Liste der
einzubindenen Quellen (vom DatenTyp InternetResource) sowie die in die Suche einzubindenden
Dokument-Typen und allgemeineren Sucheinstellungen (DatenTyp: SearchType).
Es benden sich damit alle Parameter einer Suche in einem Datenobjekt. Die Suche/Mediator
braucht nur dieses eine Objekt und kann damit die Suche durchführen.
SearchType
Bildet die Suchpräferenzen aus den Vorgaben des UserAccounts ab. Hier werden z.B. die
Dokument-Typen, die gesucht werden, deniert (z.Zt. codiert als String in .getMediaCodes()),
sowie weitere Such-Globale (also nicht auf eine bestimmte Quelle bezogenen)
Einstellungen.
InternetResource
Ein Interface, das für alle Quellen, d.h. alle eingebundenen Bibliotheks-Kataloge sowie
digitale Bibliotheken, speziell implementiert werden muss. Alle angebundenen Quellen
müssen zumindest eine Funktion getName() unterstützen, die den Typ der Quelle (codiert
als Integer) zurückgibt. Der jeweils für die Suchquelle nötige Wrapper wird durch diesen
Wert identiziert, und ein spezialisierter Wrapper verarbeitet dann die für diese Quelle
202

16.4. MEDIATOR / WRAPPER
oder auch diesen Typ Quelle nötigen Attribute (z.B. AbfrageURL, Username, Passwort
usw.).
Abbildung 16.9.: Paket org.pgportal.ejb.dto: Struktur der Anfrage Objekte
Die speziellen Attribute für die Quellen werden, sofern nötig, im UserAccount gesetzt.
Die dazwischenliegenden Schichten (Suche, Mediator,...) sehen nur das allgemeine Interface
InternetResource.
Das SearchObject enthält nachher je nach ausgewählten Suchquellen eine Menge von
InternetResourcen.
Ergebnis-Objekte
Der Mediator liefert nach durchgeführter Suche die folgenden Ergebnis-Objekte:
SearchResultSet
Beinhaltet das komplette Suchergebnis (als Array aus ResultElement(en)) sowie einige
Metadaten, wie z.B. Datum/Uhrzeit der Suche, Anzahl der Suchergebnisse, die Abfragezeit
und zusätzlich das Anfrage-Objekt (SearchObject), welches die Suche ausgelöst hat
(z.B. um dieses in eine Such-Historie zu sichern).
ResultElement
Ein ZwischenObjekt, welches Ergebnis-Gruppen (ResultGroup) und einzelne Suchergebnisse
(Result) zu einem einheitlichen Objekttyp kapselt. Ein SearchResultSet beinhaltet
also nur eine Liste aus ResultElement(en), die GUI muss so auf gruppierte Elemente
(die z.B. Ein Buchband, das aus mehreren einzelnen Büchern besteht) prüfen und eine
geeignete Darstellung wählen.
203

KAPITEL 16. ENTWURF
ResultGroup
Das Suchergebis ist eine Dokument-Gruppe (wie z.B. Schillers gesammelte Werke Band I-
XI). Die einzelnen Dokumente erhält man mit getDocGroup() als Array vom Typ Result.
Hier besteht theoretisch noch das Problem, dass die einzelnen Results von Quellsystem
(z.B. URICA) noch weiter verkapselt sein können. Der jeweilige Wrapper wird dies jedoch
berücksichtigen und das Suchergebnis (zumindest vorerst) auf eine Verkapselungsebene
herunterbrechen.
Result
Ein einzelnes Dokument mit den dazugehörigen Daten (Titel, Autor, ISBN, ...) sowie
anderen, zum Teil quellen-spezischen Metadaten (z.B. IDs o.ä.).
Abbildung 16.10.: Paket org.pgportal.ejb.dto: Struktur der Ergebnis Objekte
Struktur Mediator
Der Mediator ist als Enterprise Java Bean (EJB) realisiert und stellt der Suchlogik eine
Methode search() zur Durchführung einer parallelen Suche auf den denierte(n) InternetResource(n)
zur Verfügung. Im Weiteren werden hier die Zugrie auf das URICA
Benutzerkonto realisiert. Der Mediator verfügt somit über folgende Methoden:
search()
Die Suchfunktionalität. Es wird ein SearchObject mit entsprechenden Anfragen (Suchtyp,
Suchart, Quellen) übergeben, anhand dessen dann Wrapper instantiiert werden, die die
Suchanfrage durchführen und das Ergebnis in einem SearchResultSet zurückliefern.
204

16.4. MEDIATOR / WRAPPER
Der Mediator sammelt die einzelnen SearchResultSets und führt sie (unter Eliminierung
von Duplikaten) zu einem Einzelnen zusammen, welches dann an die aufrufende Funktion
zurückgeliefert wird.
getDocList()
Eine URICA-spezische Funktion, die die Abfrage des Benutzerkontos im ORBIS System
ermöglicht um einen Status über ausgeliehene Bücher, Mahnungen u.Ä. zu erhalten.
reserveDoc(ResultElement r)
Durch diese Funktion wird es dem userAccount-Bean möglich sein, ein Dokument aus der
Ergebnismenge einer URICA Suche am URICA System für den Benutzer zu resevieren.
Hierbei kann es sich (da ResultElement) sowohl um ein einzelnes Dokument als auch um
eine DokumentGruppe handeln - der Mediator führt dann für jedes Element der Gruppe
eine Vorreservierung durch.
deletreservedDoc(int ID)
Eine Methode, um eine bestehende Resevierung anhand der ID aus dem Benutzerkonto
zu löschen.
Struktur Wrapper
Die Wrapper werden als Message Driven Beans (MDB) realisiert. Eine MDB arbeitet
im Gegensatz zur EJB quasi-unabhängig von der Klasse, die sie instantiiert hat. Wird
eine normale EJB referenziert (instanziiiert), steht sie der aufrufenden Klasse dann im
Prinzip wie eine normale Java-Klasse zur Verfügung - d.h. wird eine Methode der Bean
abgeabeitet, geht der Kontrolluss an die Bean über - die aufrufende Klasse muss warten
bis die Bean einen Rückgabewert liefert oder abbricht.
Parallele Suche
Da man im EJB-Container JBoss aber keine Möglichkeiten preisgibt, aktiv ein threading
zu forcieren, ist auf diesem Wege eine parallele Abarbeitung mehrerer Suchquellen nicht
möglich. (Im Sinne der Skalierbarkeit von Application-Servern wird das Threading in
Bean-Klassen von JBoss restriktiv unterbunden)
Aus diesem Grunde greifen wir an dieser Stelle auf Message Driven Beans zurück: eine
MDB arbeitet im Gegensatz zur normalen EJB über JMS-Kanäle - sogenannte Queues -
: eine Klasse, die eine MDB nutzen will, instantiiert die MDB als Empfänger einer dem
System bekannten JMS-Queue, schickt eine JMS-Nachricht auf diese Queue (z.B. ein Java-
Datenobjekt) und kann dann auf einem ggf. anderen JMS-Antwortkanal (Antwort-Queue)
zu einem späteren Zeitpunkt das AntwortObjekt abholen.
Eine MDB kann aber durchaus mehr als nur eine Methode implementieren, auch wenn das
Arbeitsprinzip (Objekt empfangen - verarbeiten - zurückgeben) recht beschränkt scheint:
Eine MDB könnte z.B. für verschiedenartige Eingangsobjekte unterschiedliche Aktionen
ausführen.
Durch das MDB Konzept ist es uns nun möglich, mehrere Wrapper parallel anzustossen:
Zur Durchführung einer Suche spaltet der Mediator das zur Anfrage verwendete Search-
Object in mehrere SearchObject(e) auf, die dann jeweils nur noch eine InternetResource
enthalten. Es werden entsprechend der Anzahl Quellen WrapperMDBs instantiiert, die alle
auf dieselbe vordenierte JMS-AnfrageQueue hören, auf die dann auch die SearchObjekte
vom Mediator gesendet werden.
Nachdem nun jede Wrapper-Instanz ein SearchObject abgearbeitet hat, holt der Mediator
die Ergebnisse aus der ResultQueue wieder ab.
205

KAPITEL 16. ENTWURF
Die einzelnen Suchen werden also parallel angestoÿen - es besteht allerdings durch ungeschickte
Wahl der Reihenfolge beim Einsammeln der Ergebnisse die Gefahr(JMS-
Nachrichten enthalten Metadaten (z.B. eine eindeutige ID) an denen man sie identizieren
kann) - und da der Mediator JMS-Nachrichten nur anhand dieser eindeutigen IDs aus der
Result-Queue auslösen kann, dass man die langsamste Quelle zuerst auszulesen und zu
verarbeiten versucht, was zu unnötiger Wartezeit führt.
Erweiterbarkeit und Wartung
Im Prinzip werden alle Wrapper (ob URICA, GBV oder Citeseer...) durch eine Message
Driven Bean-Klasse im Package org.pgportal.wrapper deniert.
Da wir aber vor allem aus Gründen der Erweiter- und Wartbarkeit des Codes unsere Wrapper
möglichst quellunabhängig realisieren wollten und nicht für jede angebundene digitale
Bibliothek eine eigene MDB incl. Queues denieren wollen, beinhaltet dieses Paket nicht
viel mehr als eine einzelne MDB (WrapperMDB), welche die JMS-Kommunikationslogik
hält, und ein Interface DefaultWrapper, welches die Struktur eines Wrappers deniert.
Für die verschiedenartigen Schnittstellen zu den Quellen stehen nun jeweils Sub-Packages
unterhalb von org.pgportal.wrapper zur Verfügung, die jeweils zumindest eine Klasse enthalten,
die das Interface DefaultWrapper als normale Java Klasse implementieren. Die
WrapperMDB kann nun anhand des Types der im SearchObject enthaltenen InternetResource
(Integer-Wert: mit getName() auszulesen) entscheiden, welche Standart-Java-
Klasse genutzt werden muss, um diesen Typ InternetResource zu verarbeiten.
Die Entwicklung und Integration einer neuen Such-Quelle, also eines neuen Wrappers in
das fertige System, ist später komplett unabhängig von der verwendeten Kommunikationslogik
zwischen Wrapper/Mediator/Suchlogik/Benutzerkonto - es sind noch nicht mal
spezielle EJB- oder JMS-Kentnisse nötig, um das System zu erweitern. Die Abfrage der
neuen Quelle wird von einer Standard-Java Klasse implementiert (die natürlich in der
Lage sein muss die Ergebnisse in die entsprechenden Ergebnis-Objekte zu transferieren)
- weiterhin es ist lediglich nötig, einen neuen Typ InternetResource zu denieren und in
der WrapperMDB zu deklarieren, welcher Wrapper für diese Resource zu wählen ist.
Zwingend implementiert werden muss für die InternetResource nur getName(). Auÿerdem
kann man noch weitere Attribute ablegen, die für die entsprechende Quelle spezisch sind
(z.B. Suche nur nach ausleihbaren Dokumenten im Fall des Urica-Wrappers). Diese
spezischen Funktionen müssen entsprechend von UserAccount gesetzt und dann vom
Wrapper interpretiert werden. Der Name (getName()) muss eindeutig sein, da er auch zur
Identizierung der Ressource (des Wrappers) verwendet wird.
Die von DefaultWrapper abgeleitete Klasse muss die Methode search() implementieren
und hier entsprechend ein SearchObject entgegennehmen, anhand der hier vorgegebenen
Parameter eine Suche auf der Quelle durchführen und das Ergebnis in einem SearchResultSet
zurückliefern.
Zur Erweiterung wird man zwangsläug auch die UserAccountBean entsprechend anpassen
müssen, da sonst die neue Ressource bei der Erstellung des SearchObjektes nicht
berücksichtigt wird.
Die Package-Struktur stellt sich zur Zeit wie folgt dar:
206

16.4. MEDIATOR / WRAPPER
Abbildung 16.11.: Paket org.pgportal.ejb.wrapper : Struktur
SRU-Schittstelle zu URICA
Die Anbindung der Universitätsbibliothek wird über eine SRU-Schnittstelle realisiert. Eine
SRU-Anfrage entspricht einer Basis-URL und einem dynamisch zusammenzusetzendem
Anfrageteil, der aus Key-Value-Paaren besteht. Als Antwort wird ein XML-Dokument
zurückgeliefert.
Die Anfrage an die SRU-Schnittstelle von URICA wird von drei Klassen realisert: UricaSRURessource,
die das Interface InternetResource implementiert, SRUWrapper, die das
Interface DefaultWrapper implementiert, und der Klasse SRUParser, die das Parsen des
Ergebnisses übernimmt.
Methode
getName()
getUser()
getPW()
setUser(String)
setPW(String)
Funktionalität
gibt den Namen der InternetRessource zurück
gibt den Benutzernamen zurück
gibt das Passwort zurück
setzt den Benutzernamen
setzt das Passwort
Tabelle 16.2.: Klasse UricaSRURessource
207

KAPITEL 16. ENTWURF
Methode
search(SearchObject)
Funktionalität
führt die Suche durch und liefert ein SearchResult-
Set zurück
Tabelle 16.3.: Klasse SRUWrapper
Methode
SRUParser()
startDocument()
endDocument()
startElement(String,
String, Attributes)
endElement(String,
String)
characters(char[], int, int)
result(String, String)
String,
String,
Funktionalität
Konstruktor
wird am Anfang des zu parsenden Dokuments aufgerufen
wird am Ende des zu parsenden Dokuments aufgerufen
wird bei einem önenden Tag aufgerufen
wird bei einem schlieÿenden Tag aufgerufen
liefert den Inhalt zwischen önendem und schlieÿendem
Tag
liefert eine Hashtable mit den Elementen und den
Inhalten als Key-Value-Paare zurück
Tabelle 16.4.: Klasse SRUParser
Z.39.50 Schnittstelle zum GBV Gesamtkatalog
Der GBV Gesamtkatalog stellt eine wichtige Suchquelle dar, da sich Dokumente aus diesem
Katalog evtl. sogar durch Fernleihe über das URICA-System zugänglich machen
lassen.
Allerdings ist zum aktuellen Zeitpunkt noch kein Wrapper-Prototyp einsatzfähig, der das
Z.39.50 Protokoll implementiert.
OAI-Schittstelle zu CiteSeer
CiteSeer stellt seine Daten als OAI-Datarepository zur Verfügung. Da auf diesem keine
Suchfunktion möglich ist, müssen diese Daten zuerst in einer lokalen Datenbank abgelegt
werden. Dieses Harvesten wird von einem externen Programm regelmäÿig durchgeführt,
um den Datenbestand aktuell zu halten.
Die Suche auf dem lokalen Datenbestand lässt sich dann mit einfachen SQL-Querys auf
der Datenbank erledigen, so dass hier nur sehr geringer Overhead entsteht.
Die Anfrage an die OAI-Schnittstelle von CiteSeer wird von zwei Klassen realisert: CiteSeerRessource,
die das Interface InternetResource implementiert, CiteSeerWrapper, die
das Interface DefaultWrapper implementiert und das Suchen und Verpacken der Ergebnisse
übernimmt.
208

16.5. BENUTZERKONTO
Methode
getName()
getUser()
getPW()
Methode
search(SearchObject)
Funktionalität
gibt den Namen der InternetRessource zurück
gibt null zurück da nicht benötigt
gibt null zurück da nicht benötigt
Tabelle 16.5.: Klasse CiteSeerRessource
Funktionalität
führt die Suche durch und liefert ein SearchResult-
Set zurück
Tabelle 16.6.: Klasse CiteSeerWrapper
16.4.5. Ausblick
In der Überprüfungsphase bendet sich noch eine weitere digitale Quelle (die gewerblich
betriebene Internetpräsenz des Grin-Verlages auf http://www.hausarbeiten.de bzw.
http://www.diplomarbeiten24.de ) mit einem Volumen von ca 50.000 Dokumenten, von
denen allerdings nur ca 15.000 frei zum Download verfügbar sind.
Hier kann eine denierte XML-Schnittstelle zur Suche herangezogen werden, allerdings
ist noch nicht klar, inwieweit mit Beschränkungen bezüglich der Verfügbarkeit der Dokumente
aufgrund der kommerziellen Ausrichtung des Angebotes zu rechnen ist.
Einer Integration der Schnittstelle steht allerdings durch den modularen Aufbau der Mediator/Wrapper
Struktur nichts im Wege.
16.5. Benutzerkonto
Das Benutzerkonto dient dem Benutzer zur Beschleunigung der Suche und zum Erhalt
von Informationen über sein Bibliotheksbenutzerkonto.
Die Suche kann der Besucher beschleunigen, indem er im Konto die Sucheinstellung (wie
die Auswahl des Dokumententyps) vornimmt. Diese Einstellungen werden dann bei allen
Suchverfahren übernommen und müssen nicht immer neu bestimmt werden.
Die Informationen, die er in der Dokumentenübersicht einsehen kann, betrit sein Bibliothekskonto
und die darauf vermerkten Dokumente. So kann der Benutzer mit einem Klick
seine Ausleihfristen (oder Ähnliches) überblicken.
16.5.1. Technologien und Modelle
Die Anbindung an die Datenbank, in welcher sämtliche Daten des Benutzerkontos gespeichert
werden, wird mit Hibernate realisiert. So lassen sich SQL-Anfragen in spezieller
Hibernate-Syntax, genannt Hibernate Query Language, in ein Java-Dokument einbinden
und an die Datenbank senden. Als Antwort wird ein Datensatz zurückgeliefert.
16.5.2. Klassenbeschreibung
Die Klassenbeschreibung des Benutzerkontos beschränkt sich auf die beiden folgenden
Klassen. Die erste Klasse, HibernateUtil, sorgt dafür, dass die aktuelle Hibernate Session
209

KAPITEL 16. ENTWURF
mit dem aktuellen Thread verbunden bleibt.
Methode
currentSession()
closeSession()
Funktionalität
Önet eine neue Hibernate-Session, falls dieser
Thread noch keine hat
Beendet die aktuelle Hibernate-Session
Tabelle 16.7.: Klasse HibernateUtil
Die Klasse UserAccountBean ist die Session Bean des Benutzerkontos. Sie implementiert
die Methoden, die für die Verwaltung des Benutzerkontos benötigt werden.
Methode
Funktionalität
getMediator()
Gibt den aktuellen Mediator zurück
setMediator(LocalMediator) Ordnet der Session einen Mediator zu
getUserAccount(int)
Holt den Datensatz des Benutzerkontos aus der Datenbank
setSearchSettings(Parameter) Dient der Einstellung der bevorzugten Suchoptionen
setRemindSettings(Parameter) Legt fest, wann und wie oft der User an Termine
erinnert werden will
setLibData(Parameter) Ändert Zugangsdaten des Users von eigenen Benutzerkonten
anderer integrierter Bibliotheken
getSearchHistory(SearchHistory) Liest die Search Strings aus, nach denen bisher gesucht
wurde
setSearchHistory(Parameter) Schreibt einen neuen Datensatz in die Suchgeschichte
extendDoc(ResultElement) Speichert eine Anfrage zur Verlängerung der Ausleihfrist
bestimmter ausgeliehener Dokumente
getDocList(int)
Liest die momentan vom User ausgeliehenen Dokumente
aus
reserveDoc(ResultElement) Reserviert Dokumente
deleteReservedDoc(int) Löscht reservierte Dokumente
getUserSearchType(int) Gibt den aktuell denierten Suchtyp (einfache/erweiterte,
globale/lokale Suche) zurück
getUserResources(int) Gibt die Internetressourcen an, auf denen die Suche
durchgeführt wird
catchHibernateException() Versucht, die Transaktion bei Auftreten eines Fehlers
rückgängig zu machen und sie nach einer Exception
zu beenden
Tabelle 16.8.: Klasse UserAccountBean
Das folgende Klassendiagramm (Abbildung 16.12) zeigt die Methoden der Klasse UserAccountBean
sowie ihre Abhängigkeit zu anderen Klassen. Die Bean unterstützt den Local-
Client-View durch das Remote-Home-Interface LocalUserAccount und das Local-Home-
Interface LocalUserAccountHome. Die UserAccountBean kann auf die oben beschriebene
Klasse HibernateUtil zugreifen. Auÿerdem verwendet sie noch die Klasse SearchHistory
zur Speicherung und zum Auslesen der persönlichen Suchgeschichte des Users, sowie die
Klasse UserAccountObject zur Datenhaltung.
210

16.5. BENUTZERKONTO
Abbildung 16.12.: Klassendiagramm des Benutzerkontos
16.5.3. Dynamikbeschreibung
Nach dieser ausführlichen Beschreibung der Klassen des Benutzerkontos folgt eine Erklärung
der möglichen Anwendungsfälle.
Abrufen der Einstellungen des Benutzerkontos
Der Nutzer wählt auf seiner Benutzungsoberäche die Einstellungen des Benutzerkontos
(Sucheinstellungen, Benachrichtigungseinstellungen und Account der digitalen Bibliothek)
aus. Von der GUI wird diese Anfrage als Parameter an das UserAccountPortlet übergeben
und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage getUserAccount() mit der userID an Hibernate und bekommt
dafür das UserAccountObject zurückgeliefert, so dass sie es in der Session speichern kann.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, alle Einstellungen anzuzeigen,
samt Daten übermitteln (siehe Abb. 16.13).
211

KAPITEL 16. ENTWURF
Abbildung 16.13.: Sequenzdiagramm: Abrufen der Einstellungen des Benutzerkontos
Abrufen der Suchgeschichte
Der Nutzer wählt auf seiner Benutzungsoberäche die Suchgeschichte aus. Von der GUI
wird diese Anfrage als Parameter an das UserAccountPortlet übergeben und an die
UserAccountBean weitergegeben.
Die Bean schickt die Anfrage getSearchHistory() mit der userID an Hibernate und bekommt
dafür das SearchHistoryObject zurückgeliefert, so dass sie es in der Session speichern
kann.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Suchgeschichte anzuzeigen,
samt Daten übermitteln (siehe Abb. 16.14).
Abbildung 16.14.: Sequenzdiagramm: Abrufen der Suchgeschichte
Abrufen der Dokumentenübersicht
Der Nutzer wählt auf seiner Benutzungsoberäche die Dokumentenübersicht aus. Von der
GUI wird diese Anfrage als Parameter an das UserAccountPortlet übergeben und an die
UserAccountBean weitergegeben.
Die Bean schickt die Anfrage getDocList() mit der userID an die MediatorBean, die sie
an den Wrapper weiterleitet.
212

16.5. BENUTZERKONTO
Vom Wrapper wird die Liste der Dokumente über die MediatorBean an die UserAccount-
Bean zurückgegeben, die diese in der aktuellen Session speichert.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Liste der Dokumente
anzuzeigen, samt Daten übermitteln (siehe Abb. 16.15).
Abbildung 16.15.: Sequenzdiagramm: Abrufen der Dokumentenübersicht
Ändern des Accounts der digitalen Bibliothek
Der Nutzer wählt auf seiner Benutzungsoberäche den Account der digitalen Bibliothek
aus, ändert ihn und wählt aus, diese Änderungen zu speichern.
Von der GUI werden diese Anfrage und alle Änderungen als Parameter an das UserAccountPortlet
übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage setLibData mit der userID und allen Änderungen an Hibernate
und bekommt dafür eine Bestätigung zurückgeliefert, die an das UserAccountPortlet
geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
übermitteln (siehe Abb. 16.16).
213

KAPITEL 16. ENTWURF
Abbildung 16.16.: Sequenzdiagramm: Ändern des Accounts der digitalen Bibliothek
Ändern der Such-/Benachrichtigungseinstellungen
Der Nutzer wählt auf seiner Benutzungsoberäche sein Benutzerkonto aus, ändert Suchoder
Benachrichtigungseinstellungen und wählt aus, diese zu speichern.
Von der GUI werden diese Anfrage und alle Änderungen als Parameter an das UserAccountPortlet
übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage setSearchSettings bzw. setRemindSettings mit der userID
und allen Änderungen an Hibernate und bekommt dafür eine Bestätigung zurückgeliefert,
die an das UserAccountPortlet geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
mit allen Einstellungen übermitteln (siehe Abb. 16.17, 16.18).
Abbildung 16.17.: Sequenzdiagramm: Ändern der Sucheinstellungen
214

16.5. BENUTZERKONTO
Abbildung 16.18.: Sequenzdiagramm: Ändern der Benachrichtigungseinstellungen
Speichern der Suchgeschichte
Der Nutzer wählt auf seiner Benutzungsoberäche sein Benutzerkonto aus und führt dann
eine Suche aus.
Von der GUI wird durch die Ausführung dieser Suche die Anfrage, die Suchgeschichte zu
speichern, mit der userID, dem searchString und der searchTime an das UserAccount-
Portlet übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage setSearchHistory mit der userID und allen anderen Parametern
an Hibernate und bekommt dafür eine Bestätigung zurückgeliefert, die an das
UserAccountPortlet geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
mit allen Einstellungen übermitteln (siehe Abb. 16.19).
Abbildung 16.19.: Sequenzdiagramm: Speichern der Suchgeschichte
Verlängerung der Dokumente
Der Nutzer wählt auf seiner Benutzungsoberäche bestimmte Dokumente aus und wählt,
dass er sie verlängern will.
215

KAPITEL 16. ENTWURF
Von der GUI werden diese Anfrage und alle Änderungen als Parameter an das UserAccountPortlet
übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage extendDoc mit dem ResultElement über den Mediator an
den Wrapper und bekommt dafür eine Bestätigung zurückgeliefert, die an das UserAccountPortlet
geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
übermitteln. (siehe Abb. 16.20).
Abbildung 16.20.: Sequenzdiagramm: Verlängerung der Dokumente
Vormerken der Dokumente
Der Nutzer wählt auf seiner Benutzungsoberäche bestimmte Dokumente aus und wählt,
dass er sie vormerken will.
Von der GUI wird diese Anfrage samt der Identikationen der Dokumente als Parameter
an das UserAccountPortlet übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage reserveDoc mit dem ResultElement über den Mediator an
den Wrapper und bekommt dafür eine Bestätigung zurückgeliefert, die an das UserAccountPortlet
geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
übermitteln. (siehe Abb. 16.21).
216

16.5. BENUTZERKONTO
Abbildung 16.21.: Sequenzdiagramm: Vormerken der Dokumente
Löschen der vorgemerkten Dokumente
Der Nutzer wählt auf seiner Benutzungsoberäche bestimmte vorgemerkte Dokumente
aus und wählt, dass er sie löschen will.
Von der GUI wird diese Anfrage samt der Identikationen der Dokumente als Parameter
an das UserAccountPortlet übergeben und an die UserAccountBean weitergegeben.
Die Bean schickt die Anfrage deleteReservedDoc mit dem ResultElement über den Mediator
an den Wrapper und bekommt dafür eine Bestätigung zurückgeliefert, die an das
UserAccountPortlet geleitet wird.
Daraufhin kann das UserAccountPortlet der GUI den Befehl, die Bestätigung anzuzeigen,
übermitteln. (siehe Abb. 16.22).
Abbildung 16.22.: Sequenzdiagramm: Löschen der vorgemerkten Dokumente
Bis zu diesem Absatz wurden alle Arbeitsbereiche dokumentiert, auf welche nun die Be-
217

KAPITEL 16. ENTWURF
nutzungsoberäche aufsetzt.
16.6. Benutzungsoberäche
Die Benutzungsoberäche stellt die entscheidende Schnittstelle zwischen dem Benutzer
und den ablaufenden Programmen dar. Da die Portlets des Bibliotheksdienstes Bestandteil
des Liferay-Portals werden, werden diese sowohl optisch als auch strukturell an Liferay-
Vorgaben angepasst. Dabei wird groÿer Wert auf Einfachheit, Verständlichkeit und leichte
Bedienung gelegt. Obwohl das Portal aufgrund seiner Komplexität und Technologien
(Javascript) nicht den Web-Standards (W3C) entspricht und somit keine barrierefreie
Webseite mehr zulässt, werden die Portlets anhand dieser Richtlinien entwickelt.
Die Oberäche besteht aus 2 Hauptportlets, der Navigation und weiteren zusätzlichen
Portlets. Das Such-Portlet stellt die Suchfunktionen und Ergebnisse zur Verfügung. Mit
dem Benutzerkonto-Portlet ist es dem Benutzer möglich, Einstellungen einzusehen und zu
verändern. Diese Funktionen stehen nur eingeloggten Benutzern und keinen Gästen zur
Verfügung, da diese Informationen personalisiert gespeichert werden.
16.6.1. Client-seitige Darstellung
Folgende Graken zeigen die Benutzungsoberäche:
Abbildung 16.23.: GUI: Gesamtansicht im Liferay-Portal
Das Darstellungskonzept basiert auf zwei Haupt-Portlets, die beide über das Navigationsportlet
anwählbar sind. Das eine gibt das Benutzerkonto wieder, das andere die Such-
218

16.6. BENUTZUNGSOBERFLÄCHE
funktion. In dem zweiten Portlet wird je nach Wunsch aus dem Portletreiter die einfache
oder erweiterte Suche angezeigt.
Abbildung 16.24.: GUI: Liferay Navigations-Portlet
Die einfache Suche besteht aus drei Entscheidungskriterien. Zunächst gibt man das Suchwort
ein. Dieses kann ein Schlagwort, Stichwort oder Autor darstellen. Eine Zeile tiefer
kann man die Suche auf das ORBIS-Katalog beschränken oder über die Wahl global
weitere Bibliotheken einbeziehen. Zuletzt wird dem Benutzer noch ermöglicht, die Ergebnisliste
auf die zu Verfügung stehenden Medien zu reduzieren.
Abbildung 16.25.: GUI: Such-Portlet (Einfache Suche)
Die in der Abbildung 16.26 dargestellte erweiterte Suche soll den Benutzer die Möglichkeit
geben, die Suche genauer zu spezizieren. Im Prinzip werden die schon in der einfachen
Suche angegebenen Wahlmöglichkeiten in der erweiterten Suche weiter ausgearbeitet und
dierenziert. So kommen zu der einen Zeile für die Suchworteingabe in der erweiterten
Fassung noch sechs Zeilen dazu. Auf diese Art kann man alle Informationen unterbringen,
die man über das gesuchte Objekt hat. Während vier Zeilen eine feste Basis haben, stehen
neben zwei die Beschreibung frei wählbar. Durch diese Option wird dem Benutzer
ermöglicht, selbst Suchkriterien (z. B. eine ISBN-Nummer) festzulegen. Während man bei
der einfachen Suche nur den Status nur verfügbare Dokumente als Status-Einschränkung
wählen konnte, hat man bei der erweiterten Darstellung vier Möglichkeiten. Da das OR-
BIS eigentlich aus vier verschiedenen Oldenburger Bibliotheken besteht, werden diese in
der erweiterten Variante einzeln aufgezählt. Die Auswahl ORBIS oder global bleibt weiterhin
bestehen. Als Vorlage zur Dokumenttypenauswahl wurde die GBV genommen.
Dieses Aufteilungsprinzip ist in einigen Internetbibliotheken wiederzunden. Daher entschied
sich die Projektgruppe für diese Darstellungsform, um den Wiedererkennungswert
für den Benutzer zu erhöhen.
219

KAPITEL 16. ENTWURF
Abbildung 16.26.: GUI: Such-Portlet (Erweiterte Suche)
Die Ergebnisliste soll alle wichtigen Informationen wie Titel, Autor, Erscheinungsjahr,
Verlag und eine kurze Beschreibung direkt anzeigen. Der Dokumenttyp wird mittels eines
Icons dargestellt. Zudem kann man über einen Button am rechten Rand den Status des
Dokuments ersehen und ggf. direkt ausleihen oder vormerken. Über einen Klick auf den
Titel gelangt man zur Detailansicht.
220

16.6. BENUTZUNGSOBERFLÄCHE
Abbildung 16.27.: GUI: Such-Portlet (Ergebnisausgabe)
In der Detailansicht werden alle zur Verfügung stehenden Informationen angezeigt.
221

KAPITEL 16. ENTWURF
Abbildung 16.28.: GUI: Such-Portlet (Ergebnisausgabe mit Volldarstellung)
Das Benutzerkonto ist die zentrale Schnittstelle zwischen Benutzer und Bibliothekdienst.
Hier kann man die Ausgabe und Sucheinstellungen kongurieren und Bibliotheksinformationen
einsehen. In Abbildung 16.29 werden die persönlichen Daten des Benutzers
angezeigt. Diese sind identisch mit den in Liferay gespeicherten Daten. Wenn weitere
Bibliotheken an den Dienst angeschlossen werden, kann man die Proldaten dieser Bibiotheken
hier ebenfalls einsehen, falls der Benutzer für diese einen Account angelegt hat,
siehe Abbildung 16.32.
222

16.6. BENUTZUNGSOBERFLÄCHE
Abbildung 16.29.: GUI: Benutzerkonto-Portlet (Persönliche Daten)
In diesem Bereich kann der Benutzer seine Sucheinstellungen personalisieren und für zukünftige
Suchen sichern.
Abbildung 16.30.: GUI: Benutzerkonto-Portlet (Suchkriterien Einstellungen)
In der Dokumentenübersicht, siehe Abbildung 16.31, sollen bestimmte Daten des Benutzerkontos
des Benutzers aus dem URICA-System wiedergegeben werden. Diese Informationen
bestehen aus den Mahngebühren, Leihfristen und der Vormerkliste. Es sollte dem
223

KAPITEL 16. ENTWURF
Benutzer ebenfalls ermöglicht werden auf dies Informationen entsprechend zu reagieren.
Zum Beispiel durch eine Fristverlängerung.
Abbildung 16.31.: GUI: Benutzerkonti-Portlet (Dokumentenübersicht)
Der Bereich weitere Einstellungen des Benutzerkontos, soll dem Anwender ermöglichen
einige Erinnerungsfunktionen einzustellen. Zudem sollen die neben dem ORBIS stehenden
weiteren Bibliotheken hier eingebunden werden. DAzu kann der Benutzer sich zu jeder
weiteren Bibliothek einen Account anlegen. Diese Funktionen stehen vorerst aber nicht zur
Verfügung und werden erst mit eingebunden, sobald weitere Bibliotheken an das System
angeschlossen werden.
224

16.6. BENUTZUNGSOBERFLÄCHE
Abbildung 16.32.: GUI: Benutzerkonto-Portlet (Weitere Einstellungen)
Dies ist ein Beispiel für ein einfaches Portlet, welches statisch Informationen, in diesem
Fall die Önungszeiten, zur Verfügung stellt.
Abbildung 16.33.: GUI: Beispiel für ein Informations-Portlet (Önungszeiten)
Das Lesezeichen-Portlet dient dem Benutzer als Ablage für herausgesuchte Dokumente.
Diese lassen sich in diesem Portlet ablegen und später gezielt in bestimmte Formate, wie
z.B. Bibtex, exportieren.
225

KAPITEL 16. ENTWURF
Abbildung 16.34.: GUI: Lesezeichen-Portlet
16.6.2. Portletaufbau
Abbildung 16.35 zeigt die vorgesehenen Speicherorte der einzelnen Webseiten auf dem
Server. Dabei werden inhaltlich verwandte Seiten in den selben Ordnern gespeichert. Somit
sind die einzelnen Portlets voneinander getrennt und übersichtlich strukturiert. Graken
und weitere benötigte Dateien werden in weiteren separaten Ordnern gespeichert.
Abbildung 16.35.: GUI: Portlet-Struktur
226

16.6. BENUTZUNGSOBERFLÄCHE
16.6.3. JSP-Beschreibungen (Server-seitige Darstellung)
Hier werden alle JSPs und weitere Dateien beschrieben. Im Ordner images benden sich
alle benötigten Graken, während in der portlet.xml alle wichtigen Kongurationsparameter
gespeichert werden.
Datei
init.jsp
init-ext.jsp
styles.css
Funktionalität
Liferay spezische Abhängigkeiten und Erweiterungen
werden initialisiert
Liferay spezische Anpassungen der Portlets
CSS-Datei für grasche Anpassungen
Tabelle 16.9.: Allgemeine JSPs
Datei
advance_search.jsp
simple_search.jsp
results.jsp
result_simple.jsp
result_advanced.jsp
Funktionalität
Die erweitere Suchmaske
Die einfache Suchmaske
Die Ergebnisausgabe
Ein kurzer Eintrag der Ergebnisausgabe
Ein erweiterter Eintrag
Tabelle 16.10.: Such-Portlet
Datei
personal_data.jsp
document_overview.jsp
search_criterion.jsp
advance_settings.jsp
Funktionalität
Darstellung personenbezogener Daten sowie später Accountdaten
anderer Bibliotheken
Dokumentenübersicht, Mahngebühren und Hinweise
Einstellungen der Suche
Weitere Einstellungsmöglichkeiten
Tabelle 16.11.: Benutzerkonto-Portlet
Datei
bookmarks.jsp
export.jsp
Funktionalität
Anzeige der Lesezeichen
Exportfunktionen für die Lesezeichen
Tabelle 16.12.: Lesezeichen-Portlet
Datei
help.jsp
tutorials.jsp
faq.jsp
contact.jsp
Funktionalität
Allgemeine Hilfeseiten
Anleitungen für verschiedene Funktionen
Die wichtigsten Fragen und Antworten
Kontaktdaten für persönliche Beratung
Tabelle 16.13.: Hilfe-Portlet
227

KAPITEL 16. ENTWURF
Datei
opening_hours.jsp
Funktionalität
statische Datei mit Informationen
Tabelle 16.14.: Önungszeiten-Portlet
16.7. Datenbankmodellierung
16.7.1. UserAccount
Durch das Portal werden die Einstellungen (Sucheinstellungen, Benachrichtigungseinstellungen,
Bibliotheks-Accounts, etc.) und die Suchgeschichte der Nutzer verwaltet, also sind
die Entitäten UserAccount und SearchHistory notwendig, in denen die Einstellungen bzw.
die Suchgeschichte mit ihren Attributen abgespeichert werden. Ihre Verwaltung wird von
Hibernate mittels der geeigneten Datenbank-Funktionen übernommen.
Attribut Bedeutung Type
userID Matrikelnummer oder Personalnummer int(10)
libID Nutzername des Accounts der digitalen Bibliothek varchar(50)
libPassword Passwort des Accounts der digitalen Bibliothek varchar(32)
lendable Verfügbarkeit: ausleihbar tinyint(1)
unlendable Verfügbarkeit: nicht ausleihbar tinyint(1)
borrowed Verfügbarkeit: ausgeliehen tinyint(1)
afterAgreement Verfügbarkeit: nach Absprache tinyint(1)
searchArea Suchraum tinyint(1)
country Herkunftsland varchar(50)
remindDate Ablauf von Ausleihfristen tinyint(2)
remindFrequency Erinnerung an Ablauf von Ausleihfristen tinyint(2)
waitDocTime Verfügbarkeit von vorgemerkten Dokumenten tinyint(2)
book Dokumenttyp: Bücher tinyint(1)
audioMedium Dokumenttyp: Tonträger tinyint(1)
manuscript Dokumenttyp: Manuskripte tinyint(1)
article Dokumenttyp: Aufsätze tinyint(1)
onlineResource Dokumenttyp: Onlineressourcen tinyint(1)
musicBook Dokumenttyp: Musikalien tinyint(1)
cardMaterial Dokumenttyp: Kartenmaterial tinyint(1)
videoMedium Dokumenttyp: Filme, Videos etc. tinyint(1)
dataMedium Dokumenttyp: Datenträger tinyint(1)
game Dokumenttyp: Spiele, Skulpturen, etc. tinyint(1)
magazin Dokumenttyp: Zeitschriften/Serien tinyint(1)
letter Dokumenttyp: Briefe tinyint(1)
microche Dokumenttyp: Mikroformen tinyint(1)
picture Dokumenttyp: Bilder tinyint(1)
Tabelle 16.15.: Entität UserAccount
228

16.7. DATENBANKMODELLIERUNG
Attribut Bedeutung Type
ID Eindeutige ID int(11)
userID Matrikelnummer oder Personalnummer int(10)
searchTime an diesem Datum wird Suche durchgeführt datetime
searchString eingegebene Wort/Wörter zum Suchen varchar(255)
Tabelle 16.16.: Entität SearchHistory
16.7.2. OAI-Wrapper
Die Anbindung der OAI-Quelle CiteSeer benötigt, wie bereits erwähnt, eine eigene Datenbankstruktur,
in der die entsprechenden Daten der Quelle zur lokalen Suche vorgehalten
werden. Folgendes Tabellenlayout wird hierbei zur Speicherung der OAI-Metadaten sowie
der Dublin Core Dokumentmetadaten verwendet:
Entität Document zur Speicherung der einzelnen Dokumente:
Feld Beschreibung Typ
OAI Source OAI Repository Server ID int(11)
Identier Tag zur Identizierung varchar(150)
DateStamp OAI Datums-Flag date
setSpec OAI-Set varchar(50)
dc_Title Titel des Dokumentes varchar(50)
dc_Subject Thema des Dokumentes varchar(150)
dc_Publisher Herausgeber varchar(150)
dc_Description Beschreibung text
dc_Date Erscheinungsdatum date
dc_Format Format (Text/Bild/...) varchar(10)
dc_Source Dokumentquelle varchar(150)
dc_Identier Unique Identier für das Dokument varchar(150)
dc_Language Sprache varchar(10)
dc_Rights Lizenz/Copyright varchar(50)
Die Entität OAI Source hält verschiedene OAI Quellen vor:
Feld Beschreibung Typ
ID ID int(11)
Name Name der Quelle varchar(30)
URI URI der Quelle varchar(150)
Entität Person zur (separaten) Speicherung einzelner Personen:
Feld Beschreibung Typ
ID ID int(11)
Name Name der Person varchar(50)
Entität DC_Creator zur Zuordnung von Personen zu Dokumenten:
229

KAPITEL 16. ENTWURF
Feld Beschreibung Typ
document_ID ID des Dokumentes varchar(150)
person_ID ID der Person int(11)
Entität DC_Relation zur Modellierung von Beziehungen zwischen Dokumenten:
Feld Beschreibung Typ
from_Identier Quelldokument varchar(150)
to_Identier Zieldokument varchar(150)
16.8. Testablauf
16.8.1. Einführung
Dieses Kapitel gibt nicht die vollständige Entwicklung des Testverfahrens wieder. Es ist
mehr ein Abriss dessen. Man kann es als Teil der ersten Phase des Testverfahrens für
dieses Projekt ansehen; der Testplanung. Diese und die weiteren Phasen sind von dem
Standard ANSI/IEEE 829 (ISO12207) abgeleitet unter Zuhilfenahme des Buches von H.
M. Sneed und M. Winter [SW02].
16.8.2. Testverfahren
Unser Testverfahren besteht aus 6 Phasen:
1. Testplanung: In dieser Phase werden die Testziele bestimmt. Dazu betrachtet man
die Abnahmekriterien der Anforderungsdenition zu diesem Projekt. Im weiteren
werden die dazu gehörigen Aktivitäten geplant und der Testzeitraum begrenzt. Ein
wichtiger Punkt ist ebenfalls die Bestimmung der notwendigen Ressourcen.
2. Testentwurf: Hier entsteht die Konzeption der Testprozesse. Es geht darum, welche
Komponenten und Funktionen in welcher Reihenfolge und auf welche Art getestet
werden. Auf diese Weise erhält man schlieÿlich ein Testkonzept.
3. Testfallspezikation: Hierbei muss man sich Gedanken über das Verhalten des Testgegenstands
machen. Um später ein Soll-Ist-Vergleich zu ermöglichen, wird in dieser
Phase das zu erwartetende Verhalten notiert.
4. Testdurchführung: Zunächst werden die Testfälle erzeugt. Darauf werden die benötigten
Ressourcen bereitgestellt. Und anschlieÿend wird der Test durchgeführt.
5. Testauswertung: Die Testauswertung besteht aus den Protokollen, die die Zwischenstände
der verschiedenen Testabläufe festhalten und kontrollieren. Am Ende wird
ein Testbericht entwickelt, aus dem hervorgehen wird, welche auÿergewöhnlichen Ergebnisse
es gab, was noch zu verbessern ist und welche Ziele schon erreicht worden
sind.
6. Testwiederholung: Es werden die Tests wiederholt, in dessen Einussbereich Änderungen
stattgefunden haben.
230

16.8. TESTABLAUF
16.8.3. Testgegenstand
Ein Test bezieht sich immer auf einen bestimmten Gegenstand. Dieser Gegenstand wird
separat in seiner eigenen Testumgebung getestet. Die zu testenden Gegenstände sind:
• Methode: die kleinste testbare Einheit
• Klasse: die nächst gröÿere Einheit
• Klassenmenge: in diesem Projekt sind es die EJB's
• Komponente: in diesem Fall bezieht es sich auf die entwickelten Portlets oder Pakete
innerhalb der verschiedenen Schichten
• System bzw. Applikation: das bedeutet, alle für das Bibliothekssystem entwickelten
Komponenten integriert im Portal mit der zugehörigen Anbindung zur Datenbank
und den verschiedenen Bibliotheksdiensten
16.8.4. Testmethoden
Die Aufarbeitung der Testmethoden und dessen Zuteilung zu den Testgegenständen ist
der bestimmende Teil des Testentwurfs.
Statische Programmanalyse
In der statischen Programmanalyse wird die Einhaltung der Spezikationen und der für
dieses Projekt selbst aufgelegten Programmierregeln kontrolliert. Die Spezikationen, die
befolgt werden und damit auch dessen Einhaltung kontrolliert werden müssen, sind die
Portlet-Spezikationen, EJB-Spezikationen und weitere. Weiterhin wurden die Regeln
beschlossen, alle Klassen und Methoden auf englisch zu kommentieren. Die Bezeichnungen
sollen ebenfalls auf englisch sein. Dieses Analyseverfahren bezieht sich auf jeden Testgegenstand
und ist deswegen keinem spezisch zugeordnet.
Unit-Test
Der Unit-Test bezieht sich auf die Klassen und Methoden unserer Entwicklung. Man
testet, ob die Klassen und Methoden die gewünschte Arbeit verrichten, die richtigen Parameter
erzeugen und verwenden und auch die Datentypen-Spezikationen eingehalten
werden.
Integrationstest
Im Integrationstest wird die Interaktion zwischen den Testgegenständen überprüft. Das
fängt erst im Kleinen an. Denn zunächst werden die Interaktion der Klassen innerhalb
einer EJB überprüft. Dann folgt die Betrachtung eines Pakets. Und darauf werden die
einzelnen Portlets betrachtet. Die gröÿte und schwerste Arbeit ergibt sich in der Kontrolle
der Interaktionen zwischen den groÿen Komponenten. Dafür ist es besonders wichtig,
sich die Spezikationen der entwickelten Schnittstellen zu betrachten. Durch sie erkennt,
man welche Komponenten von einander abhängig sind und welche Daten erhalten oder
weitergegeben werden. Somit kann man eine Liste erstellen, aus der hervor geht, welche
231

KAPITEL 16. ENTWURF
der Komponenten miteinander direkt interagieren. Zur besseren Übersicht wird die Liste
unter Zuhilfenahme der in Abschnitt 2.2 Umzusetzende Anwendungs-Architektur
vorgestellten Schichten-Architektur weiter aufgeteilt.
Liste der direkten Interaktion und damit die gemeinsam zu testenden Komponenten:
1. Interaktion innerhalb Präsentationsschicht
• Benutzerkonto-Portlet und GUI (JSP's)
• Such-Portlet und GUI (JSP's)
• Benutzerkonto-Portlet und Such-Portlet
• Benutzerkonto-Portlet und Navigations-Portlet
• Such-Portlet und Navigations-Portlet
2. Interaktion zwischen Präsentationsschicht und Geschäftslogikschicht
• Such-Portlet und Such(Geschäfts)logik
3. Interaktion zwischen Geschäftslogikschicht und Datenzugrisschicht
• Suchlogik und Mediator
• Suchlogik und Persistenzklassen
4. Interaktion zwischen Präsentationsschicht und Datenzugrisschicht
• Benutzerkonto-Portlet und
5. Interaktion innerhalb Datenzugrisschicht
• Mediator und die verschiedenen Wrapper
6. Interaktion zwischen Datenzugrisschicht und Datenhaltungsschicht
Systemtest
• Die verschiedenen Wrapper und dem dazugehörigen Bibliotheksdienst
• Persistenzklassen und Datenbank
Beim Systemtest wird das System in seiner Gesamtheit getestet. Also so wie der allgemeine
Benutzer auf das Bibliothekssystem zugreift mit allen seinen Komponenten und dessen
benötigten Ressourcen. Zunächst wird dabei von einem intelligenten Benutzer ausgegangen.
Damit wird kontrolliert, ob allen Anforderungen an die Entwicklung genüge getan
wurden. Anschlieÿend wird diese Anwendungssoftware noch aus der Sicht eines weniger
versierten Benutzer überprüft. Somit wird die Fehlerresistenz des Bibliothekssystems Benutzereingaben
gegenüber getestet. Zur Durchführung dieser Testreihe sollen zunächst
verschiedene Testszenarien entwickelt werden.
232

16.8. TESTABLAUF
Installationstest
Da innerhalb dieses Projekts einige Spezikationen eingehalten werden (von den Portlet-
Spezikationen bis zu den Hibernate-Spezikationen), wird davon ausgegangen, dass diese
Entwicklung weitestgehend plattformunabhängig ist. Jedoch gilt das erst noch zu bestätigen.
Daher muss man das Bibliothekssystem auf verschiedenen Plattformen installieren
und ausprobieren. Auf diese Weise kann man die notwendigen Rahmenbedingungen festlegen,
die einen sicheren Arbeitsablauf der Entwicklung gewährleisten.
Performanztest
Da das Bibliothekssystem nicht nur für einen Benutzer entwickelt wurde, sondern für viele
Benutzer, die parallel damit arbeiten, muss auch die Belastbarkeit und die Robustheit
der Entwicklung ausgetestet werden. Dazu werden die schon im Systemtest entwickelten
Szenarien erneut angewendet. Der Unterschied zum Systemtest ist aber, dass weniger auf
die Fehler geachtet wird. Hierbei gilt es neben der Geschwindigkeit, in der das Produkt
sein Aufgabe erfüllt, hauptsächtlich um die Stabilität des Bibliothekssystems. Dabei muss
eine so hohe Belastung des Systems erzielt werden, dass sogar noch einem Spielraum zur
erwarteten wirklichen Belastung besteht.
233

17. Implementierung
In diesem Kapitel wird ein kurze Dokumentation der Implementierungsphase vorgenommen.
Die Schwerpunkte liegen dabei insbesondere auf einer übersichtlichen Darstellung
von Paketen und Klassen, einer Herausarbeitung von gemachten Änderungen gegenüber
dem Entwurf und der Erläuterung einiger besonderer Implementierungsdetails. Die Gliederung
des Kapitels orientiert sich einmal mehr an den vier Bereichen Suchlogik, Mediator/Wrapper,
Benutzerkonto und Benutzungsoberäche. Diese werden Umklammert
von einleitenden Erklärungen zur Datenstruktur und abschlieÿenden Erläuterungen zum
Testverlauf.
17.1. Datenstruktur
Die Datenstruktur, wie sie im Entwurfsdokument (Kapitel 16) vorgesehen war, hat sich
als recht stabil und sinnvoll erwiesen. Die vorgegebene Struktur wurde im Zuge der Implementierungsphase
weiter verfeinert, so dass sich nun ein recht komplexes Gesamtbild
ergibt (vgl. Abb. 17.1).
Die anfängliche Struktur ist aber dennoch wie vorgesehen erhalten geblieben. Einzig die
Datentransfer-Objekte, wie sie im Kapitel 16.4.4 des Entwurfs vorgesehen waren, wurden
sehr stark erweitert, so dass man sie in der aktuellen Struktur nur schwerlich wiederndet.
Auf die Anpassungen, die hier nötig waren, soll an dieser Stelle nun im Einzelnen eingegangen
werden.
234

17.1. DATENSTRUKTUR
Abbildung 17.1.: Gesamtpaketübersicht
17.1.1. Das Package org.pgportal.ejb.dto
Das Package org.pgportal.ejb.dto ist im Laufe der Entwicklung sehr komplex geworden,
so dass es sinnvollerweise in mehrere Unterpakete aufgeteilt wurde.
Im Haupt-Package (vgl. Abb. 17.2) ist eine Klasse PortalDefaults angelegt worden, die
die eigentliche Kongurationseinheit des Bibliotheksdienstes darstellt. Hier werden die
Attribute der Wrapper und die Standardwerte für neue Benutzer deniert.
235

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.2.: Paket org.pgportal.ejb.dto (globale Informationen)
Das Package org.pgportal.ejb.dto.request
Die Klassen der Anfrageobjekte sind in das Package org.pgportal.ejb.dto.request
(vgl. Abb. 17.3) gekapselt worden. Für die Suche von Bedeutung ist hier die Klasse
SearchObject, die für alle unterstützten Suchoptionen entsprechende Felder bereithält.
Diese Klasse musste im Laufe der Entwicklung eigentlich kaum angepasst werden.
Die Klasse UricaAccountRequest ist hingegen neu und hält den Benutzernamen und
den Hashwert eines Urica-Benutzerkontos für den integrierten Zugri auf die URICA
Schnittstelle zum URICA-Benutzerkonto.
236

17.1. DATENSTRUKTUR
Abbildung 17.3.: Paket org.pgportal.ejb.dto.request (Anfrage-Objekte)
Das Package org.pgportal.ejb.dto.result
Im Package org.pgportal.ejb.dto.result (vgl. Abb. 17.4) sind die Klassen für die
Repräsentation von Suchergebnissen sowie der clientseitigen Darstellung von URICA-
Benutzerkontodaten abgelegt.
237

KAPITEL 17. IMPLEMENTIERUNG
Alle Suchergebnisse haben bestimmte Felder gemein, die im Interface BasicResult deniert
sind. Die Basisklasse BasicResultImpl implementiert dieses Interface und stattet
entsprechende Objekte mit essentiellen Methoden für polymorphes Objekthandling aus.
Konkrete Suchergebnisse sind immer jeweils vom Typ Result oder ResultGroup, die beide
von BasicResultImpl abgeleitet sind und die geerbten Attribute um spezische Felder
für ein Einzelergebnis bzw. eine Ergebnisgruppe erweitern. Die Klasse SearchResultSet
stellt dabei das Wurzelelement für alle Ergebnisse einer Suchanfrage dar und hält sie
neben diversen (Meta-) Informationen über die Suche in einer Java-Collection für die
Darstellung bzw. weitere Verarbeitung bereit.
Die Klassen UricaAccountInfo und UricaAccountResult repräsentieren das URICA-
Benutzerkonto bzw. Einträge darin. Mit UricaCharge werden Mahngebühren im URICA-
System abgebildet.
238

17.1. DATENSTRUKTUR
Abbildung 17.4.: Paket org.pgportal.ejb.dto.result (Ergebnis-Objekte)
239

KAPITEL 17. IMPLEMENTIERUNG
Das Package org.pgportal.ejb.dto.definitions
Das Package org.pgportal.ejb.dto.definitions (vgl. Abb. 17.5) hält nun die Denitionsklassen
der unterschiedlichen angebundenen Quellen, die im Entwurf (noch recht grob)
unter dem Interface InternetResource waren. Hier gilt es zwei Arten von Denitions-
Klassen zu unterscheiden: zum einen die Technologie-spezischen Quellen-Denitionen
(z.B. OAIDefinition oder SRUDefinition), die jeweils ein Interface darstellen, welches
die Attribute speziziert, die das System benötigt, um z.B. eine (neue) SRU-basierte
Quelle zu integrieren und die eigentlichen InternetResourcen hier SRUResource und
OAIResource.
Abbildung 17.5.: Paket org.pgportal.ejb.dto.definitions (Objekte für allgemeine
Denitionen)
Alle quellen-spezischen Einstellungen zu einer InternetResource werden in den zum
Package gehörenden Sub-Packages (z.B. org.pgportal.ejb.dto.definitions.sru) abgelegt
hier gibt es so z.B. eine Klasse org.pgportal.ejb.dto.definitions.sru.-
SRUDefinitionLoC, die das Interface SRUDefinition implementiert und alle nötigen Attribute
für die Anbindung der Library of Congress hält (wie z.B. die Anfrage-URL uvm.).
Zur genauen Beschreibung dieser Klassen sei an dieser Stelle auf die JavaDoc verwiesen.
240

17.2. SUCHLOGIK
17.1.2. Das Package org.pgportal.ejb.mediator
Im Mediator-Package hat sich nicht viel verändert, ausser das die URICA-spezischen
Funktionen (z.B. das Abfragen des URICA-Kontos) dazu geführt haben, dass hier zwei
zusätzliche Klassen mit aufgenommen wurden. Im Detail wird hierauf im Abschnitt 17.3
eingegangen.
17.1.3. Das Package org.pgportal.ejb.search
Für die Suchlogik war im Verlaufe der Implementierung keine Anpassung der Paketstruktur
nötig. Funktionale Änderungen der Klassen werden im Abschnitt 17.2 beschrieben.
17.1.4. Das Package org.pgportal.ejb.wrapper
Das Package org.pgportal.ejb.wrapper hat nun Sub-Packages bekommen, in denen
die generischen Wrapper abgelegt sind. So beinhaltet das Sub-Package org.pgportal.-
ejb.wrapper.sru (vgl. Abschnitt 17.3.4) den Wrapper für SRU-basierte Quellen und
org.pgportal.ejb.wrapper.oai (vgl. Abschnitt 17.3.5) den Wrapper für Suchen in OAIbasierten
Quellen. Diese Verfeinerung ist dafür gedacht, um auch bei einer zukünftigen
Erweiterung, z.B. um z3950-basierte Quellen, eine klare Struktur vorzuhalten.
17.1.5. Das Package org.pgportal.ejb.userAccount
Die Änderungen im UserAccount werden im Abschnitt 17.4 beschrieben. Im Verlaufe der
Implementierung mussten hier einige Methoden angepasst werden.
17.1.6. Das Package org.pgportal.ejb.util
Das package org.pgportal.ejb.util enthält als Utility-Package Hilftklassen für den
Umgang mit EJB-Komponenten. So führt das Interface EjbJndiNames die JNDI-Namen
der EJB-Komponenten auf, damit diese mittels JNDI-lookups gefunden werden können.
Die Namensdenitionen werden etwa von der Klasse EjbLocalHomeFactory benutzt, die
das Factory-Pattern für Referenzen zu den Home-Interfaces der EJB-Komponenten umsetzt.
Abbildung 17.6.: Paket org.pgportal.ejb.util (Hilfsklassen)
17.2. Suchlogik
Das folgende Unterkapitel beschäftigt sich mit den Implementierungsdetails der Suchlogik.
Dabei wird besonders auf vorgenommene Änderungen im Vergleich zum Entwurf
241

KAPITEL 17. IMPLEMENTIERUNG
dieser Schicht eingegangen. Aber auch neue Konzepte insbesondere aus dem Bereich des
Rankings, die im Vorfeld nur sehr schlecht zu planen waren werden erläutert.
Die Implementierung der Suchlogik wurde wie im Entwurf vorgesehen mittels einer zustandslosen
SessionBean realisiert. Sie bendet sich im Paket org.pgportal.ejb.search
und beinhaltet Methoden sowohl öentliche Business-Methoden als auch private Hilfsmethoden
die sich grob in vier Gruppen klassizieren lassen, um die Hauptaufgabe
rund um das Suchen und Sortieren von Datensätzen zu bewerkstelligen. Da sind zum
einen Methoden zur Filterung und Datenbereinigung von Eingaben und Suchergebnissen
und zum anderen die Methoden zur Bestimmung der Relevanz einzelner Ergebnisse.
Des Weiteren gibt es noch Methoden zur Speicherung der Such-Chronik, genauso wie
die EJB-spezischen Methoden zur Regelung des Lebenszyklus. Im folgenden werden die
Methoden dieser vier Bereiche sowie der Suche und Sortierung selbst näher erläutert.
17.2.1. Methoden zur Suche und Sortierung
Die Business-Methoden zur Suche und zum Sortieren von Datensätzen sind die elementaren
Bestandteile der EJB und sind wie im Entwurf speziziert implementiert worden.
Die Suche als Hauptfunktion führt zahlreiche Unteraufgaben aus, wie das Kontrollieren
der Suchparameter, das Weiterleiten der bereinigten Parameter zur eigentlichen Suche an
den Mediator, das Filtern und Anpassen der erhaltenen Ergebnisse, die Ermittlung eines
Relevanzwertes für die Ergebnisse, die Sortierung der Ergebnisse nach Vorgabe des Benutzers
sowie eine Speicherung der Suchanfrage für die Such-Chronik. Alle diese Funktionen
wurden auf kleinere Teilfunktionen heruntergebrochen, die zum Teil wiederum kleinere
Teilfunktionen nötig machten. Die Wartbarkeit wurde durch dieses Vorgehen erheblich
gesteigert. Die entsprechenden Hilfsmethoden werden dann in den nachfolgenden vier
Abschnitten beschrieben.
• search(): Diese Business-Methode ist die Hauptfunktion der EJB. Sie bekommt die
Suchparameter in Form eines SearchObjects vom Portlet übergeben und initiiert
zunächst eine Kontrolle der Parameter auf richtige Angaben und erlaubte Zeichen.
Die bereinigten Parameter werden nun zur eigentlichen Suche an den Mediator delegiert.
Die zurückgelieferten Ergebnisse werden dann geltert, angepasst und mit
einem Rankingwert versehen. Erst jetzt ndet eine Sortierung nach den Angaben
des Benutzers und mit Hilfe der Hilfsmethode doSort() statt. Abschlieÿend folgt
noch die Speicherung der Suchanfrage in der Datenbank.
• sort(): Diese Business-Methode führt eine Sortierung einer Ergebnismenge durch.
Ein Parameter gibt dabei an, nach welchem Kriterium die Suchergebnisse sortiert
werden sollen. Die eigentliche Sortierung wird durch die Hilfsfunktion doSort()
ausgeführt, so dass diese Funktionalität von mehreren Methoden genutzt werden
kann.
• doSort(): Diese Methode nimmt die Sortierung einer Ergebnismenge vor.
17.2.2. Methoden zur Filterung und Datenbereinigung
Im Entwurf zur Suchlogik sind nur Methoden zur groben Aufgabenteilung speziziert
worden insbesondere die Business-Methoden. Ein feineres Methodengerüst mit allen
242

17.2. SUCHLOGIK
nötigen Hilfsmethoden sollte erst zur Implementierung folgen. Die Aufgaben zur Filterung
und Datenbereinigung der Eingaben und Suchergebnisse können sehr komplex ausfallen.
Im folgenden die implementierten Methoden:
• checkParam(): Diese Methode überprüft die Eingaben, die der Benutzer bei der
Eingabe einer Suchanfrage macht. Sie verhindert u. a. eine Eingabe von HTML-
Tags.
• checkUID(): Diese Methode prüft, ob die UserID gesetzt ist.
• charReplacer(): Diese Methode ersetzt bestimmte Zeichen(ketten) durch andere.
Sie wird insbesondere von der Methode checkParam() verwendet, um z. B. die
Zeichen zum Ausführen von HTML-Code zu ersetzen.
• filterResults(): Mittels dieser Methode ndet eine Filterung der übergebenen
Ergebnisse statt. Hauptziel ist eine Bereinigung und Vereinheitlichung der einzelnen
Felder eines Ergebnisses. Die folgenden Hilfsfunktionen kommen an dieser Stelle zum
Einsatz.
• removePunctuationMarks(): Diese Methode entfernt unnötige Satzzeichen am Ende
einer Zeichenkette, wie z. B.: , . ; ! oder ?.
• chopSuffixChars(): Diese Methode kürzt eine Zeichenkette um eine andere, sollte
sie sich am Ende der Zeichenkette benden.
• chopPrefixChars(): Diese Methode kürzt eine Zeichenkette um eine andere, sollte
sie sich am Anfang der Zeichenkette benden.
• eliminateDublicateAbstracts(): Diese Methode überprüft, ob es unter den Abstracts
eines Dokuments Duplikate gibt und entfernt diese entsprechend.
17.2.3. Methoden zur Relevanzbestimmung
Eine weitere wichtige Aufgabe im Rahmen der Suchfunktion stellt die Bestimmung der
Relevanz eines Ergebnisses dar. Da Kriterien für die Relevanz eines Ergebnisses in hohem
Maÿe subjektiv sind und viele der im Entwurf angesprochenen Technologien aufgrund der
Nutzung zahlreicher verschiedener Bibliotheksangebote und Schnittstellen nicht umgesetzt
werden können, liegt das Hauptaugenmerk auf das Berücksichtigen von Vorkommen
der Suchbegrie in den Ergebnisfeldern.
Der Berechnungsschlüssel zur Bestimmung der Relevanz eines Wertes ist sehr dierenziert.
Ohne nun im Detail erklären zu wollen, wie sich ein Relevanzwert konkret errechnen
lässt, sollen nun ein paar umgesetzte Ideen dazu beschrieben werden. Es werden exakte
und fast exakte Vorkommen des Suchstrings gezählt und berücksichtigt. Auch einzelne
Wörter des Suchstrings werden dahingehend in das Kalkül einbezogen wobei zwischen
Wortklassen unterschieden und unterschiedlich gewichtet wird. Das bedeutet, dass z. B.
Artikel weniger ins Gewicht fallen als normale Nomen. Genauso werden die Wort- und
Suchstringvorkommen für jedes Eingabefeld anders bewertet. Die Anzahl der Treer in
einem Abstract z. B. wird mit dem logistischen Wachstum gewichtet, um die Länge von
Abstracts in eine vergleichbare Relation zur Länge von Titel- oder Autorenfeldern zu
setzen. Auch wird berücksichtigt, in welcher Bibliothek ein Ergebnis gefunden wurde.
243

KAPITEL 17. IMPLEMENTIERUNG
Das Erstellen eines ausgewogenen Relevanzsystems bedarf vieler Tests mit unterschiedlichen
Parametereinstellungen für die unterschiedlichen Faktoren und Gewichte. Die Implementierung
der vorgestellten Ideen wurde durch die folgenden Methoden realisiert.
• calcRelevance(): Diese Methode ist der zentrale Einstiegspunkt für die Relevanzberechnung.
Sie bekommt die Ergebnismenge übergeben und weist jedem Ergebnis
einen Relevanzwert zu.
• setElementRelevance(): Diese Methode bekommt ein Suchergebnis und die Suchparameter
übergeben und bestimmt anhand dieser Daten einen Relevanzwert.
• iterateRelevanceCalculation(): Diese Hilfsmethode von setElementRelevance()
berechnet einen Relevanzwert aus einem Faktor, dem Suchstring und dem Ergebnis.
• calcStringDistance(): Diese Hilfsmethode ermittelt einen Relevanzfaktor mittels
Aufsummieren von unterschiedlichen Vorkommen von Suchwörtern in den Ergebnisfeldern.
• calcOccurences(): Diese Methode zählt die Anzahl der Vorkommen eines Suchbegris
in einem Ergebnisfeld hier nur in Abstracts und gewichtet diese Anzahl
mit dem logistischen Wachstum.
• countOccurences(): Diese Methode zählt die Vorkommen einer Zeichenkette in
einer anderen Zeichenkette.
17.2.4. Methoden zur Speicherung der Such-Chronik
Um gemachte Suchanfragen auch später nachvollziehen zu können, wird dem Benutzer eine
Such-Chronik eine chronologisch sortierte Liste ausgeführter Suchanfragen angeboten.
Zu diesem Zweck hält die Suchlogik Methoden zum Speichern und Abfragen von Anfragen
vor. Auch können alle gespeicherten Anfragen eines Benutzers aus der Datenbank entfernt
werden. Zur Speicherung einer Suchanfrage, wird das entsprechende SearchObject als
Datenobjekt, das alle Parameter zu einer Suche kapselt serialisiert als BLOB in der
Datenbank abgelegt.
• setSearchHistory(): Diese Methode legt eine Suchanfrage in Form eines Search-
Objects in der Datenbank ab.
• getSearchHistory(): Mittels dieser Methode wird die Such-Chronik zu einem Benutzer
aus der Datenbank geholt.
• removeSearchHistory(): Diese Methode entfernt alle gespeicherten Suchanfragen
eines Benutzers aus der Datenbank.
• serialize(): Diese Methode serialisiert ein SearchObject in ein BLOB zur Speicherung
in der Datenbank.
• deserialize(): Diese Methode deserialisiert ein BLOB zurück in ein SearchObject.
244

17.2. SUCHLOGIK
17.2.5. EJB-spezische Methoden
Die EJB-spezischen Methoden müssen von jeder EJB implementiert werden - sie regeln
den Lebenszyklus. Diese folgenden Methoden halten sich an die Sun EJB 2.1 Spezikation
1 :
• ejbCreate()
• ejbRemove()
• ejbActivate()
• ejbPassivate()
• setSessionContext()
17.2.6. Klassenbeschreibung
Bei der Implementierung der oben erläuterten Methoden wurde in hohem Maÿe auf eine
hohe Wartbarkeit und eine klare Aufgabenverteilung hinsichtlich der Funktionalität der
Methoden geachtet. Teilaufgaben wurden, wo es Sinn machte, in neue Methoden ausgegliedert,
so dass Funktionalität nicht redundant implementiert wurde. Eine Übersicht des
Aufbaus der Klasse der SessionBean sowie eine Darstellung ihrer Beziehungen zu anderen
Klassen und implementierten Interfaces liefert Abbildung 17.7.
Abbildung 17.7.: Klassendiagramm der Suchlogik
1
http://java.sun.com/products/ejb/ - J2EE Enterprise JavaBeans Technology
245

KAPITEL 17. IMPLEMENTIERUNG
17.3. Mediator / Wrapper
Im Folgenden wird auf Besonderheiten bzw. Auälligkeiten im Zuge der Implementierung
des Mediators bzw. des Wrappers eingegangen.
17.3.1. Mediator
Das Mediator-Konzept zur Zusammenführung sämtlicher Suchergebnisse hat sich im Laufe
der Entwicklung des Gesamtsystems als sehr nützlich und sinnvoll erwiesen. Der Mediator
stöÿt die eigentliche Suche an, er instantiiert entsprechend der Anzahl der zu durchsuchenden
Quellen die Wrapper, die die eigentliche Suchanfrage durchführen, und führt
deren Ergebnisse zusammen. Dieses Konzept wurde entsprechend der Spezikationen im
Entwurf umgesetzt.
Einzig die Duplikateliminierung bzw. das Zusammenführen von mehreren Exemplaren
als eine Entität hat sich im Nachhinein als etwas komplizierter als zuvor angenommen
herausgestellt. Die Suchergebnisse, die die einzelnen Quellen liefern, sind nicht immer
vollständig oder korrekt: So kommt es vor, dass eine Suche z.B. zwei Dokumente mit
gleichem Titel und denselben Autoren liefert, aber dann bei einem Exemplar keine (oder
eine eindeutig falsche) ISBN-Nummer ausgibt. In solchen nicht eindeutigen Fällen geht
der Mediator pessimistisch vor und liefert dann schonmal zwei Dokumente, anstatt diese
als Dokumentgruppe mit zwei Exemplaren zusammenzuführen. Hier hat sich auch gezeigt
wie stark Quellen qualitativ voneinander abweichen können: Die von uns zusätzlich über
SRU mit eingebundene National Science Digital Library, die online verfügbare Dokumente
indiziert, liefert so z.B. sehr häug Duplikate, von denen ein Groÿteil auch noch nicht
lesbare Zeichen, die durch fehlerhafte utf-8 Konvertierung entstanden sind, im Titel oder
im Abstract haben.
Ebenfalls ärgerlich war, dass es uns nicht möglich gewesen ist, das bestehende Bibliothekssystem
ORBIS komplett einzubinden. Wir sind zwar in der Lage das Benutzerkonto von
ORBIS auszulesen sofern der Benutzer des Systems die entsprechenden Daten (Urica-ID
und Password) zur Verfügung stellt aber unsere Schnittstelle zu ORBIS erlaubt leider
nicht das Vormerken eines Dokumentes, da dieses wohl zu Kollisionen mit dem bestehenden
System führen würde.
Die Struktur des Mediators ist im Abb. 17.8 aufgezeigt.
246

17.3. MEDIATOR / WRAPPER
Abbildung 17.8.: Klassendiagramm des Mediators
17.3.2. Methoden des Mediators
Die eigentlichen Business-Methoden des Mediators sind:
• search(): Diese Methode führt die Suche durch. Hier werden die Wrapper über eine
JMS-Queue angestoÿen, die Ergebnisobjekte abgewartet und eine Duplikateliminierung
durchgeführt. Die Suchlogik (= die Schicht die diese Methode benutzt) kann
nun auf einem kompletten SearchResultSet, das die Ergebnisse sämtlicher Quellen
enthält, ihre Relevanzbestimmung ausführen und Optimierungen vornehmen.
• checkUricaAccountInfo(): Diese Methode ist für das Überprüfen von UserName-
Passort Tupeln für Das URICA-Konto gedacht. Faktisch führt der Mediator ein
Login bei URICA aus und testet, ob dieser erfolgreich war.
• getUricaAccountInfo(): Die eigentliche Schnittstelle zum URICA-Konto. Hier
wird eine komplette Statusabfrage des URICA-Accounts durchgeführt.
Die EJB-spezischen Methoden (vgl. Abschnitt 17.2.5 bei der Suchlogik) sowie die nötigen
EJB-Interfaces sind hier natürlich ebenso vorhanden, sollen aber nicht extra nochmals
erklärt werden.
Im Gegensatz zum Entwurf nutzt der Mediator zwei zusätzliche Klassen (UricaAccount-
Connector und UricaAccountParser) zum Aufbau der Verbindung zum URICA System
247

KAPITEL 17. IMPLEMENTIERUNG
bzw. zum Parsen der URICA Antwort (XML). Im ursprünglichen Entwurf war vorgesehen,
diese Funktionalitäten komplett mit in die EJB zu nehmen, was aber aus Gründen der
Übersichtlichkeit und Lesbarkeit im Code externalisiert wurde. Das XML-handling wird
über einen SAX-Parser realisiert.
17.3.3. Wrapper
Die Wrapper haben sich in der Implementierung (vgl. Abb. 17.9) hinsichtlich des Entwurfs
nicht verändert. Es handelt sich nach wie vor um Message-Driven Beans, die über
das Interface DefaultWrapper den jeweils richtigen, d.h. zur Quelle passenden Wrapper
instantiieren und die Suche anstoÿen.
Abbildung 17.9.: Paket org.pgportal.ejb.wrapper (DefaultWrapper)
17.3.4. SRU-Wrapper
Der SRU-Wrapper (Abb. 17.10) ist sozusagen der älteste unter den Wrappern und der
erste, der die Struktur im Entwurf komplett umgesetzt hat. Da das SRU-Protokoll XMLbasiert
ist und nicht bei allen SRU-Quellen ein (korrektes) XML-Schema vorlag, haben
wir den generischen SRU-Wrapper auf Basis eines SAX-Parsers implementiert.
Die Klasse SRUWrapper stellt hier die Verbindung zum jeweiligen SRU-Server (basierend
auf den Daten, die für die Quelle in der SRUDefinition hinterlegt sind), und stellt die
Anfrage in Form der SRU-üblichen cql-Notation.
Das Parsen der resultierenden XML-Antwort des Servers übernimmt dann der SRUParser,
der einen typischen SAX-Handler implementiert (daher Methoden wie startDocument,
endDocument, etc). Der Handler regiert auf die jeweiligen Tags, die in der SRUDefinition
dieser spezischen Quelle hinterlegt sind (z.B. XML_TAG_AUTHOR) und ordnet
die identizierten Werte im Result-Objekt zu.
248

17.3. MEDIATOR / WRAPPER
Abbildung 17.10.: Paket org.pgportal.ejb.wrapper.sru (Wrapper zur Suche auf SRUbasierenden
Quellen)
17.3.5. OAI-Wrapper
Aufgrund der Änderungen der Datenstruktur in den DTOs wurde auch der OAI-Wrapper
auf eine entsprechende Struktur bestehend aus Denitions-Objekten angepasst. Die resultierende
Struktur sowie die dadurch nötigen Änderungen werden anschlieÿend im einzelnen
erläutert.
249

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.11.: Klassendiagramm des OAI-Wrappers
Der OAIWrapper greift im Gegensatz zu den anderen Wrappern nicht auf eine externe
Suchquelle zurück, sondern führt die Suchfunktionen eigenständig auf einer lokalen Datenbank
durch. Die Daten für die Suche werden dabei vom OAIHarvester (17.3.5) aus
OAI Online-Repositories eingesammelt und in das entsprechende lokale Datenformat konvertiert.
Durch die lokale Datenhaltung ist eine eziente Suche auch auf sehr groÿen Datenbeständen
möglich, so dass der OAI-Wrapper das Potential hat, die Quelle mit den meisten und
besten (Online-)Ergebnissen zu werden. Dies hängt allein davon ab, welche Quellen der
lokalen Datenbank hinzugefügt und somit dem Wrapper bekannt gemacht werden.
Änderung und Ergänzungen zum Entwurf:
• Die Klasse OAIWrapper verwendet das hinzugekommene Interface OAIDenition
um, je nach OAI-Quelle, einige grundlegende Daten festzulegen und Denitionen
(RepositoryURL, . . . ) zu erhalten.
• Die Methode search() führt anhand der Denition eine Suche via hibernate in
einer per jndi referenzierten Datenbank durch und liefert die entsprechenden Ergebnisse
als SearchResultSet zurück.
250

17.3. MEDIATOR / WRAPPER
Abbildung 17.12.: Klassendiagramm des OAI-Harvester
Der OAIHarvester war ursprünglich als ein externes Programm geplant, welches in regelmäÿigen
Abständen die bekannten OAI-Quellen überprüft und den lokalen Datenbestand
aktuell hält. Durch das von hibernate abhängige komplexe Datenschema erschien es allerdings
sinnvoller, den Harvester direkt mit den anderen EJBs zu integrieren, so dass auf
eine gemeinsame Grundlage (Denitions, Hibernate-Objekte, . . . ) zurückgegrien werden
konnte.
Aufbau und Funktionsweise:
• Die Klasse HarvesterBean und deren entsprechendes RemoteInterface implementiert
einen OAI Harvester, der anhand einer OAIDefinition eine Anfrage an ein
online OAI-Repository stellt und einen chunk XML-Datensätze via hibernate
mit den entsprechend lokal vorgehaltenen Daten abgleicht bzw. neue Datensätze
hinzufügt.
• Die Methode update() nimmt eine OAI-Anfrage von einem Remote-Client entgegen
und führt diese mit Hilfe der Methode harvest() durch. Sollte diese Anfrage an das
OAi-Repository ein resumptionToken zurückliefern, (d.h. es existieren noch weitere
Datensätze, die bisher nicht gesendet wurden) wird dieses Token an den aufrufenden
Client zurückgeliefert, der somit die Möglichkeit hat, die Anfrage fortzusetzen.
Die exakte Erläuterung des Ablaufes eines OAI-Harvests würde an dieser Stelle den Rahmen
sprengen. Hierzu sei auf die ausführliche Dokumentation der Open Archives Initiative
verwiesen (http://www.openarchives.org).
251

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.13.: Paket org.pgportal.ejb.wrapper.OAI (OAI-Objekte)
• Die Klassen des Pakets org.pgportal.ejb.wrapper.OAI im Hibernate-Modul dienen
allein der persistenten Datenspeicherung via hibernate in einer SQL-Datenbank.
17.4. Benutzerkonto
Im Vergleich zum Entwurf wurde die Struktur der Java-Klassen und der Datenbank aus
verschiedenen Gründen geändert. Im folgenden werden die Änderungen detailliert erläutert.
Alle Klassen liegen in dem Package org.pgportal.ejb.userAccount (siehe Abbildung
17.14).
252

17.4. BENUTZERKONTO
Abbildung 17.14.: Klassendiagramm des Benutzerkontos
• Klasse HibernateUtil wurde gelöscht, da die Struktur von Hibernate komplett umgebaut
wurde. Die entsprechenden Funktionen der Klasse HibernateUtil wurden
in die Methoden integriert, um damit auf die Datenbank zuzugreifen.
• Klasse UserAccountBean
Um die Testumgebung anzupassen, wurde das Attribut UserID von int auf String
geändert.
Die Methoden extendDoc(), reserveDoc() und deleteReservedDoc() wurden
von der Implementierung ausgeschlossen, weil ein aktiver Zugri des Portals
auf die Bibliotheksfunktionen, wie Verlängerung, Vormerkung und Löschen
der Vormerkung der Dokumente, von Seiten des IBIT / BIS nicht gewünscht
ist.
Die Methode getDocList() wurde durch die Methode getUricaAccountInfo()
ersetzt. Der Kontostand des Benutzers, sowie die Übersicht der ausgeliehenen
und vorgemerkten Dokumente werden dadurch von ORBIS geholt.
Die Methode getUserSearchType() wurde zu getDefaultSO() umbenannt.
Die liefert ein SearchObject zurück, welches die vom Benutzer vordenierten
Sucheinstellungen enthält.
253

KAPITEL 17. IMPLEMENTIERUNG
Die Methode getUserResources() wurde durch getWrapperList() ersetzt,
die die vom Benutzer vordenierten Bibliotheken zur Suche zurückliefert. Die
Methode setWrapperList() wurde auch eingefügt, diese speichert die vom
Benutzer geänderten Bibliotheken in die Datenbank.
Einige Methoden wurden eingefügt.
∗ checkUserAccount() prüft, ob der Eintrag des Benutzers in der DB existiert.
Wenn nicht, dann wird ein Eintrag mit Standard-Werten automatisch
in die DB gespeichert.
∗ checkUricaAccount() dient zur Prüfung, ob der Benutzer sein ORBIS-
Konto in der DB gespeichert hat. checkUricaAccountInfo() prüft, ob der
vom Benutzer eingegebene Benutzername und sein Passwort von ORBIS
richtig ist.
∗ checkWrapperList() vergleicht die in der DB gespeicherten Bibliotheken
und die vom Portal angebotenen Bibliotheken. Wenn die beide nicht stimmen,
dann werden die Bibliotheken in der DB aktualisiert.
∗ resetSearchHistory() dient zur Rückstellung der Suchgeschichte, wenn
der Benutzer die Anzahl der zu speichernden durchgeführten Suchen ändert.
In den Methoden getWrapperList() und setWrapperList() wird direkt ein
Wrapper-Objekt (siehe Abbildung 17.15) erzeugt mit denen dann weitergearbeitet
wird. Ebenfalls in der Methode checkWrapperList() kann gegeben falls
ein Wrapper-Objekt erzeugt werden.
Abbildung 17.15.: Paket org.pgportal.ejb.userAccount (Benutzerkonto-Objekte)
• Klasse LocalUserAccount
Das Local-Interface wurde nach der Änderung der Klasse UserAccountBean entsprechend
angepasst.
• Klasse userAccountObject enthält die Attribute userID, libID, libPassword,
resultQuantity, historyQuantity, saveLibData und entsprechende setter- und
getter-Methoden. Die Attribute zu den Dokumenttypen existieren nicht mehr, weil
die nicht von ORBIS und anderen Bibliotheken unterstützt werden.
254

17.5. BENUTZUNGSOBERFLÄCHE
• Klasse Wrapper wurde eingefügt. Sie enthält die Attribute id, userID, name und
active. Die vom Benutzer gewählten Bibliotheken werden dadurch in der DB gespeichert
oder aus der DB geholt.
Für mehr Details über das Package org.pgportal.ejb.userAccount sei auf die entsprechenden
Javadocs verwiesen.
17.5. Benutzungsoberäche
Abbildung 17.16 und Abbildung 17.17 zeigen die aktuelle Portlet- und Paketstruktur.
Im Vergleich zur geplanten Struktur (siehe Abbildung 16.35) wurden einige JSP-Dateien
umbenannt und neue hinzugefügt. Um die Seite graphisch aufzuwerten, wurden die lizenzfreien
Silk Icons von Mark James 2 integriert und alle bisherigen Graken durch diese
ersetzt.
Abbildung 17.16.: GUI: Portlet-Struktur
2
http://www.famfamfam.com/lab/icons/silk/ - Creative Commons Attribution 2.5 License
255

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.17.: Pakete org.pgportal.portlet und org.pgportal.portlet.util
Abbildung 17.18.: GUI: Vergleich der Gesamtansicht, siehe Abb. 16.23
Die bedeutendste Änderung am Layout erfolgte durch die Einbindung des neuen Uni-
Themes in Liferay. Alle weiteren Entwicklungen und Design wurden gezielt auf die neuen
Farben und Schriften ausgerichtet. Folgende Abbildungen zeigen einige deutliche Unterschiede
zwischen Entwurf und aktueller Umsetzung.
256

17.5. BENUTZUNGSOBERFLÄCHE
Abbildung 17.19.: GUI: Vergleich der Einfachen Suche
Abbildung 17.20.: GUI: Vergleich der Ergebnis-Anzeige, siehe Abbildung 16.27
257

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.21.: GUI: Vergleich der Detailansicht eines Ergebnisses, siehe Abbildung
16.28
258

17.5. BENUTZUNGSOBERFLÄCHE
Abbildung 17.22.: GUI: Vergleich der Einstellungen
259

KAPITEL 17. IMPLEMENTIERUNG
Abbildung 17.23.: GUI: Vergleich der Dokumentenübersicht, siehe Abbildung 15.10
Von den ursprünglich geplanten zusätzlichen Portlets Lesezeichen (siehe Abbildung
15.13) oder Önungszeiten (siehe Abbildung 15.12) konnte aufgrund der knapp bemessenen
Zeit keines mehr verwirklicht werden. Diese werden daher Bestandteil der Weiterentwicklung
des Bibliotheksdienstes sein. Dafür wurde das Suchportlet um eine weitere
Funktion erweitert. Dem Benutzer steht nun eine Suchchronik zur Verfügung, in der seine
letzten Suchen aufgelistet werden und durch einen einfachen Klick nochmal gestartet
werden können.
260

17.6. ERLÄUTERUNGEN ZUM TESTVERLAUF
Abbildung 17.24.: GUI: Portlet Suchchronik
Abbildung 17.25.: GUI: Ausschnitt aus der Hilfe
17.6. Erläuterungen zum Testverlauf
In dem Dokument Entwurf (siehe Kapitel 16) wurde ein Testplan ausgearbeitet, der als
richtungweisend für den den wahren Testverlauf gelten sollte.
261

KAPITEL 17. IMPLEMENTIERUNG
Zunächst muss hier verdeutlicht werden, dass dieser Testplan von einer eigenständigen
Arbeitsphase ausging. Das bedeutet, dass die Entwicklung des Projekts zum gröÿten Teil
zu diesem Zeitpunkt schon abgeschlossen sein sollte, und die Testphase dazu dienen sollte
Fehler zu erkennen, die bei der einfachen Implementierung übersehen wurden.
Jedoch wurde schnell ersichtlich, dass diese Planung aus Zeitgründen nicht umzusetzen
war. Daher entstand der Beschluss, dass die Arbeitsphasen Implementierung und Testen'
parallel durchgeführt werden müssen.
Um dieses Prinzip verständlicher zu machen, wird nun ein typischer Arbeitsprozess kurz
vorgestellt:
• Entwicklung oder Veränderung eines Wrappers
• Einbindung des Wrappers in das laufende System
• Testen durch Ausführung von mehreren Suchanfragen
• Bei Fehlern wird der Prozess neugestartet
• Bei fehlerfreier Funktion gilt dieser Wrapper zunächst als korrekt und der nächste
Arbeitsabschnitt wird angegangen.
Durch dieses Konzept wird nicht nur die selbständige Testphase gestrichen. Sondern es
entfällt auch die Zusammenstellung einer Arbeitsgruppe, die die Tests durchführt. Diese
Arbeit wird jetzt durch den Entwickler, der das zu testende Objekt selbst erzeugt hat,
vorgenommen. Als Folge konnte man ein hohen Zeitgewinn verbuchen.
Allerdings wurde aus dem alten Konzept noch die Gestaltung einer Testumgebung ins
neue Konzept übernommen. Mit dem Testserver und -client wurde erst ein ausführliche
Überprüfung der entwickelten Software möglich.
Auf den ersten Blick hätte sich das Testverhalten damit auf dem Schwerpunkt Integrationstest,
was ursprünglich nur ein Teil des eigentlichen Testplans war, festgelegt. Da
diese Art der Überprüfung nicht als ausreichend zu verstehen ist, wurde die Intensität des
Kontrollverhaltens ausgebaut. Damit meint man, dass jede kleinste Veränderung, zum
Beispiel die Überarbeitung einer Funktion oder die Einführung eines anderen Datentyps,
dazu führte, dass eine neue Testreihe ausgeführt wurde, um das Verhalten des neu gestalteten
Objekts zu überprüfen. Damit erklären sich auch die hohen Revisionszahlen im
SVN-Repository, das für dieses Projekt zur Verbesserung des Teammanagements angelegt
wurde. Teilweise wurde diese Art des Verfahrens so intensiv ausgeführt, dass nur die
Umsetzung eines Flags in der GUI-Struktur eine Prüfung der Gesamtstruktur zu Folge
hatte. Weiterhin entstanden für kurze Zeit zu Testzwecken selbständig Gruppen zwischen
2-4 Personen, wenn es darum ging, bestimmte Komponenten auf ihre Zusammenarbeit zu
testen. Diese Phasen der direkten Teamkommunikation erzeugten intensive und gezielte
Untersuchungen der Problemfelder. Wie die Kommunikation zwischen Wrapper, Mediator,
Such-Logik und GUI.
Auf diese Art und Weise wurde ein Vereinigung der verschiedenen Testverfahren erzielt:
Unit-Test, Integrationstest und Systemtest.
Zudem wurden ebenfalls die statische Programmanalyse und der Installationstest berücksichtigt.
Diese beiden Verfahren beinhalten die Überprüfung der Einhaltung der Spezikationen.
Dadurch das die maÿgebenden Spezikationen von vornherein befolgt wurden,
262

17.6. ERLÄUTERUNGEN ZUM TESTVERLAUF
kann man sich sicher sein, dass deren Einhaltung besteht. Damit wurde den beiden Testabläufen
zuvor gekommen. Somit erzielte man den gleichen Erfolg als wären sie separat
ausgeführt worden.
Unter den gegebenen Voraussetzungen erreichte man aufbauend auf dem beschriebenen
Konzept den bestmöglichen Testablauf.
263

18. Handbuch
18.1. Suche
Den Kern dieser Anwendung stellt die Suche in verschiedenen Bibliothekskatologen dar.
Für eine schnelle und unkomplizierte Nutzung steht die Einfache Suche zur Verfügung.
Um auch gezieltere Suchen vornehmen zu können, sollte auf die Erweiterte Suche zurückgegrien
werden. Abgerundet wird die Suchfunktion durch eine Such-Chronik. Sie
ermöglicht eine Archivierung der zuletzt getätigten Such-Aktionen, die auf diese Weise
komfortabel und bequem nochmals eingesehen und ausgeführt werden können.
18.1.1. Einfache Suche
Die Einfache Suche besteht aus lediglich einem Eingabefeld, so dass einer unkomplizierten
Anwendung nichts im Wege steht. Ein in dieses Eingabefeld eingetragener Begri wird
zugleich in allen Kategorien 1 (Autor, Title usw.) gesucht. Geben Sie als Beispiel das Wort
Müller ein, nden Sie sowohl Dokumente von Autoren dieses Namens als auch Dokumente
die vom Beruf des Müllers handeln. Diese Art der Suche bietet sich insbesondere
dann an, wenn Sie schnell an vielen Ergebnissen zu einem Thema interessiert sind oder
sich einfach nur an relevante Begrie / Jahreszahlen erinnern, von denen Sie nicht genau
wissen, ob sie im Titel oder im Inhalt vorkommen.
Abbildung 18.1.: Einfache Suche, Eingabefeld der Suche
Unterhalb des Eingabefeldes für die Suchbegrie bietet die Einfache Suche die Möglichkeit
an, den Suchraum auf verschiedene Bibliothekskataloge einzuschränken. So können
Sie entweder nur im Katalog der Universitätsbibliothek Oldenburg suchen (es genügt dazu
den ORBIS-Katalog auszuwählen), die Suche auf sämtliche eingebundenen Quellen
zu erweitern (in diesem Fall bitte global auswählen) oder Sie nutzen die Möglichkeit
auf einem von Ihnen selbst festgelegten Suchraum zu suchen (in diesem Fall bitte benutzerdeniert
auswählen). Den Suchraum können Sie im Benutzerkonto durch einfaches
Auswählen der gewünschten Bibliotheken festlegen.
1
jhfhmjgf
264

18.1. SUCHE
Abbildung 18.2.: Einfache Suche, Denition des Suchraums
Eine Einfache Suche kann unter Umständen sehr viele Ergebnisse zurück liefern, da wie
schon angesprochen in allen Kategorien nach den eingegebenen Begrien gesucht wird. In
diesen Fällen sollten Sie Ihre Suche einschränken, indem Sie entweder mehrere Suchbegrie
eingeben oder die Erweiterte Suche verwenden.
18.1.2. Erweiterte Suche
Mit Hilfe der Erweiterten Suche ist es möglich, dierenziert nach Begrien in bestimmten
Kategorien zu suchen. Während bei der Einfachen Suche alle Dokumente als Ergebnisse
ausgegeben werden, in denen sich das Suchwort in einer der Kategorien bendet, liefert
die Erweiterte Suche nur diejenigen Dokumente zurück, in denen der Suchbegri in der
angegebenen Kategorie oder Bibliothek gefunden wurde. Auf diese Weise kann z. B. ganz
gezielt nach einem Autor oder einem Titel gesucht werden. Selbstverständlich können
auch die Suchfelder kombiniert werden. Dazu reicht es aus, die gewünschten Felder mit
den entsprechenden Suchbegrien zu füllen und die Suche abzuschicken. Jedes Feld mit
einer Eingabe wird auch bei der Erweiterten Suche berücksichtigt.
Abbildung 18.3.: Erweiterte Suche, verschiedene Kategorien: Titel, Autor und Schlagwort
265

KAPITEL 18. HANDBUCH
Zusätzlich wird es Ihnen ermöglicht, den Suchraum für die durchzuführende Suche selbst
festzulegen. Durch ein einfaches Setzen eines Häkchens neben denjenigen Bibliotheken, in
denen Sie nach den Suchbegrien suchen wollen, legen Sie diesen Suchraum fest. Dabei
sind selbstverständlich alle Kombinationsmöglichkeiten erlaubt.
Abbildung 18.4.: Erweiterte Suche, Deniton des Suchraums
Die Bilder neben den Bibliotheksnamen geben die Medientypen wieder, die dort zur Verfügung
stehen.
Abbildung 18.5.: Erweiterte Suche, ndbare Medientypen
18.1.3. Such-Chronik
Wenn Sie eine Wiederholung einer bereits gemachten Recherche durchführen wollen,
können Sie mit Hilfe der Such-Chronik auf vergangene Suchen zurückgreifen. Die Such-
Chronik listet dazu die zuletzt durchgeführten Suchanfragen mit Kennzeichnung durch
Datum, Uhrzeit, Suchart und Suchbegri(en) in einer chronologisch sortierten Tabelle auf.
266

18.1. SUCHE
Ein einfacher Klick auf einen solchen Sucheintrag bewirkt die nochmalige Ausführung der
gemachten Suchanfrage. Diese Funktion ist auch dann sehr nützlich wenn man einfach nur
mal gucken will, wonach man zuletzt gesucht hat. Die Such-Chronik muss nicht gesondert
aktiviert werden - sie wird automatisch mitgeführt. Lediglich die Anzahl der zu speichernden
Suchanfragen kann festgelegt werden. Diese Festlegung ndet im Benutzerkonto
statt.
Abbildung 18.6.: Such-Chronik
18.1.4. Ergebnisanzeige
Die Ergebnisanzeige besteht aus zwei Teilen. Der erste Teil ermöglicht die Wahl des Sortierverfahrens
und gibt ein paar Statistiken an. Das zweite Teilstück ist auch gleichzeitig
das Herzstück, denn hier werden die Ergebnisse wiedergegeben.
Im ersten Teil kann man rechts oben das Sortierverfahren auswählen. Somit wird es Ihnen
ermöglicht, selbst zu bestimmen nach welchen Gesichtspunkten (Relevanz, Datum usw.)
die Ergebnisliste sortiert werden soll.
Die Statistiken geben für die in der Suche berücksichtigten Quellen, die im Suchraum
bestimmt wurden, die Menge der dort gefundenen Medien wieder. Zusätzlich wird noch
die Dauer der Suchabfrage im einzelnen und im ganzen ersichtlich.
Abbildung 18.7.: Ergebnisanzeige, Statistiken
Von den Suchergebnissen werden zunächst nur die Titel und der Teil indem das Suchwort
steht wiedergeben. Auf diese Weise können viele Suchergebnisse übersichtlich dargestellt
werden. Das Bild neben dem Titel gibt den Medientyp wieder, so dass direkt ersichtlich
ist, um was für einen Medentypen es sich bei dem gefundenen Dokument handelt. Durch
267

KAPITEL 18. HANDBUCH
das Anklicken des Titels eines Ergebnisses erhält man zusätzliche Informationen über das
gefundene Dokument.
Abbildung 18.8.: Ergebnisanzeige, aufgeklapptes Ergebnis
18.2. Benutzerkonto
Das Benutzerkonto ermöglicht es dem Benutzer, bibliotheksdienstrelevante Einstellungen
zu koordinieren oder Informationen zu erhalten.
18.2.1. Einstellungen
In diesem Bereich können Einstellungen vorgenommen werden. Diese Einstellungen wirken
sich direkt auf den Bibliotheksdienst aus, so dass Sie hiermit die Möglichkeit haben,
die angebotenen Funktionen ihren Wünschen entsprechend anzupassen. Die gemachten
Kongurationen können selbstverständlich gespeichert werden, so dass vermieden wird,
dass einige Dinge immer wieder erneut einzustellen sind.
Die Einstellungsmöglichkeiten beziehen sich hierbei auf den Suchraum, die Ergebnisanzeige
und der Such-Chronik.
Abbildung 18.9.: Benutzerkonto, Einstellungen
Die Vorgaben für den Suchraum werden bei beiden Suchverfahren übernommen. Hierbei
268

18.2. BENUTZERKONTO
werden diese in der einfachen Suche durch die Auswahl benutzerdeniert wiedergegeben.
Weiterhin kann man die Anzahl der jeweils auf einer Seite angezeigten Suchergebnisse
bestimmen.
Zuletzt besteht noch die Möglichkeit die Zahl der innerhalb der Such-Chronik zu speichernden
Suchen einzustellen.
18.2.2. Dokumentenübersicht
In der Dokumentenübersicht werden die von Ihnen ausgeliehenen und vorgemerkten Dokumente
angezeigt. Sollten Mahngebühren angefallen sein, sind diese ebenfalls auf dieser
Seite zu sehen. Die Dokumentenübersicht gliedert sich in die drei Bereiche Mahngebühren,
ausgeliehene Dokumente und vorgemerkte Dokumente.
Unter Mahngebühren nden Sie von Ihnen ausgeliehene Dokumente, deren Leihfrist überschritten
ist, so dass Gebühren fällig werden. Zu jedem Dokument wird das Rückgabedatum,
der Titel und die Gebühren angezeigt.
Abbildung 18.10.: Benutzerkonto, Mahngebühren
Darunter nden sich Ihre ausgeliehenen Dokumente, deren Leihfristen noch nicht abgelaufen
sind. Auch hier werden Rückgabedatum und der Titel angegeben. Sollte die Möglichkeit
zur Verlängerung der Leihfrist bestehen, also kein anderer Benutzer das Dokument
vorgemerkt haben und die maximale Anzahl an Verlängerungen nicht ausgeschöpft sein,
nden Sie nach dem Titel eine Schaltäche mit der Beschriftung verlängern.
Abbildung 18.11.: Benutzerkonto, selbst ausgeliehene Dokumente
Im untersten Abschnitt sind Ihre Vormerkungen zu sehen. Es werden Daten der voraussichtlichen
Verfügbarkeit, der Titel des Dokuments und eine Schaltäche zum Löschen
der Vormerkung angezeigt.
269

KAPITEL 18. HANDBUCH
Abbildung 18.12.: Benutzerkonto, eigene Vormerkungen
18.2.3. Persönliche Daten
Auf dieser Seite werden Ihre persönlichen Daten angezeigt, die im Liferay-Portal hinterlegt
sind. Da diese Angaben nur einmal für das gesamte Portal gespeichert werden, sind
Änderungen nur in Portalaccount möglich, den Sie per Klick auf den Link unterhalb ihrer
Daten erreichen.
18.3. Navigation
Abbildung 18.13.: Benutzerkonto, persönliche Daten
Es gibt zwei Navigationsarten. Einmal als eigener Bereich (Portlet), der für die Hauptfunktionen
zu ständig ist. Und dann noch die Reiter innerhalb den anderen Bereichen
(Suche usw.).
18.3.1. Hauptnavigation
Über die Hauptnavigation erreicht man die Bereiche Suche, Benutzerkonto und Hilfe.
270

18.3. NAVIGATION
Abbildung 18.14.: Navigation, Ausgangszustand
Wenn man einer dieser Seiten aufgerufen hat und anschlieÿend wechseln will, muss man
in der Hauptnavigation auf Bibliothek klicken, um eine andere Seite aufrufen zu können.
Abbildung 18.15.: Navigation, Zustand nach Wahl einer Hauptseite
18.3.2. Navigation innerhalb der Seiten
Um auf die verschiedenen Funktionen der einzelnen Seiten wechseln zu können, muss man
die Reiter bedienen die oben in den Seiten angezeigt werden.
Abbildung 18.16.: Reiter innerhalb der Seiten
271

19. Zusammenfassung und
Bewertung
Der folgende Abschnitt nimmt einen Rückblick auf den Verlauf des Projekts auf mehreren
Ebenen vor. Angefangen mit einer kurzen Zusammenfassung der wichtigsten Arbeitsschritte
und Ergebnisse des abgelaufenden Jahres, schlieÿt sich dem eine detaillierte
Darstellung der in den einzelnen Projektphasen gemachten Erfahrungen an. Abgerundet
wird der Abschnitt durch eine Bewertung des Projekts auf der einen Seite und des
entwickelten Bibliotheksdienstes auf der anderen.
19.1. Zusammenfassung
Die Projektgruppenarbeit gliederte sich in verschiedene Phasen. Der Einstieg in die Thematik
wurde durch unsere Betreuer gegeben, die uns das entstehende Portal vorstellten.
In der Seminarphase wurden Vorträge mit Bezug zu Portalsystemen, Projektarbeit, digitale
Bibliotheken und Metadaten gehalten, um einen Einblick in die für unsere Aufgabe
relevante Themen zu bekommen und so das Umfeld kennenzulernen, in das unser Projekt
eingebettet ist.
Im Anschluss daran begann die konkrete Beschäftigung mit Onlineauftritten von Bibliotheken.
Es wurde ein Kriterienkatalog erarbeitet, mit dessen Hilfe Angebote verschiedener
Bibliothekswebseiten bewertet wurden. Aus den Ergebnissen entstand ein erstes Sollkonzept
für unser Portlet. Dieses bildete die Grundlage für die Anforderungsdenition.
Da Gruppenarbeit mit 12 Teilnehmern kaum ezient möglich ist, wurden Untergruppen
von 3 4 Leuten gebildet, die jeweils mit einer Teilaufgabe (GUI, Benutzerkonto,
Suchlogik und Mediator/Wrapper) beauftragt wurden. Die regelmäÿigen Treen der Gesamtgruppe
dienten hauptsächlich dazu, den anderen Untergruppen die Fortschritte und
/ oder Probleme der eigenen Arbeit zu berichten, neue Aufgaben zu verteilen oder Entscheidungen
zu treen, die die gesamte Gruppe betrafen.
Ein erster Prototyp wurde erstellt, der das Zusammenspiel aller beteiligten Schichten demonstrierte
und einen Eindruck von der zu realisierenden Klassenstruktur gab. Es folgte
das Entwurfsdokument, dessen Fertigstellung sich trotz aller guten Vorsätze doch etwas in
die Länge zog. Also begann die Implementierungsphase auch später als es im wohlweislich
nie aufgeschriebenen Projektzeitplan vorgesehen war. Doch wie immer wird unter Termindruck
am eektivsten gearbeitet und so ist das Uni-Portal jetzt um ein Bibliotheksportlet
reicher.
Die Arbeit der PG war natürlich nicht nur ergebnis-, sondern auch stark prozeÿorientiert,
da es sich um eine Lehrveranstaltung handelte. Alle Beteiligten hatten schon Erfahrung in
Softwareentwicklung im Team mindestens durch das Softwareprojekt im Grundstudium.
So gelang die Einigung auf eine gemeinsame Basis relativ schnell. Es wurden Verantwortliche
für die Webseite, die Dokumentensammlung, die Projektleitung usw. gefunden.
272

19.2. ERFAHRUNGSBERICHTE
Bei den Entwicklungswerkzeugen wurde jedem weitestgehend selbst überlassen, was verwendet
werden sollte. Nur beim Erstellen von Graken aller Art, z.B. Klassendiagramme,
wurde sich aus Gründen der Einheitlichkeit auf das Eclipse-UML-Plugin von Omondo
geeinigt. Unverzichtbar für die gemeinsame Entwicklung von Software ist die Versionskontrolle,
in unserem Fall durch svn. Die eingerichte Webseite diente in der Anfangszeit
dem Austausch durch das Forum und der Dokumentensammlung. Es wurde ein zentraler
Testserver eingerichtet, da aufgrund der Komplexität der Anwendung lokal entwickelter
Code nicht immer portabel war. Da die Implementierungsphase zwar die intensivste, aber
auch die kürzeste war, blieb hier kaum Zeit für Werkzeuge über die Nötigsten hinaus. Am
Ende ist ein Bibliotheksdienst zu bestaunen, der nicht nur die regionalen Bibliotheken
einbindet, sondern auch Online-Ressourcen zugänglich macht (und sogar den Bestand der
Library of Congress in Washington durchforstet).
Beim Gestalten der Projektplanung herrschte kreative Freiheit. Deadlines wurden meist
erst mit wachsendem Termindruck gesetzt und eingehalten aber der Erfolg gab uns
Recht. Gruppenarbeit erfordert ein hohes Maÿ an Zuverlässigkeit, Absprache, Toleranz,
Geduld und diversen anderen Soft-Skills. Nicht nur das termingerechte Erbringen von
Leistungen, sondern auch das Respektieren anderer Arbeitsweisen, das Akzeptieren von
Misserfolgen, das Nicht-Einmischen in andere Arbeitsbereiche, das Annehmen und Üben
von konstruktiver Kritik, das Aushalten nicht immer optimaler gruppendynamischer Prozesse
und vieles andere mehr erfordern Selbstdisziplin und Einschränkung des Egos jedes
einzelnen. Dieses zu Üben und an unserer Teamfähigkeit zu arbeiten, gab uns das vergangene
Jahr viele Möglichkeiten. Das Arbeitsklima in der Gruppe war jederzeit positiv.
Fussballturnier, Kaee und Kuchen sorgten für Gemeinschaft über die Projektarbeit hinaus
(siehe Anhang B).
19.2. Erfahrungsberichte
In diesem Abschnitt werden gemachte Erfahrungen aus den einzelnen Phasen des Projekts
dargelegt.
19.2.1. Vorbereitungsphase
Als sich zu Beginn des Sommersemesters 2005 zwölf Studenten und Studentinnen zum ersten
Treen der Projektgruppe mit dem Titel Ein Studierendenportal für die Uni Oldenburg
zusammenfanden, wusste wohl noch keiner der Teilnehmer, was auf ihn zukommen
würde. Somit wurde diese erste Sitzung für organisatorische Dinge genutzt, wie das gegenseitige
Vorstellen oder die allgemeine Klärung von Sinn und Zweck einer Projektgruppe.
Am wichtigsten für den Anfang war jedoch eine ungefähre Abgrenzung des Themas und
der Anforderungen, die sich hinter diesem verheiÿungsvollen Titel verbargen. Schnell wurde
klar, dass es nicht darum ging, ein komplettes Studierendenportal zu entwickeln, wie
man es vielleicht aus dem Titel entnehmen konnte. Vielmehr sollte der Fokus auf der
Entwicklung und Integration von einzelnen Komponenten in ein solches Portal liegen, das
an anderer Stelle im Rahmen des i 3 -sic-Projektes konzipiert wurde. Bei den zu entwickelnden
Komponenten sollte es sich um Bibliotheksdienste handeln. Weitere thematische
Einschränkungen wurden zunächst nicht gemacht, so dass die Klärung der Anforderungen
an die zu entwickelnden Dienste zum Bestandteil des Projektauftrags wurde.
273

KAPITEL 19. ZUSAMMENFASSUNG UND BEWERTUNG
19.2.2. Seminarphase
Nach diesen ersten Gesprächen zur Vorstellung des Projekts wurden auch einige technische
Vorgaben angesprochen, wie die Umsetzung der Dienste in Portlets, die Integration
der Portlets in das Liferay-System oder die Implementierung in Java. Keiner der zwölf
Teilnehmer hatte zu diesem Zeitpunkt Erfahrungen mit der Portlet-Technologie oder der
Liferay-Portalsoftware, so dass sich jeder im Verlauf des Projekts auf Neuland begeben
musste. So trocken die übergeordnete Thematik um Bibliotheksdienste auch für den ein
oder anderen geklungen haben mag, nach der Klärung der einzusetzenden Technologien
war das Interesse allerseits geweckt.
Zum Kennen lernen dieser neuen Technologien wurde eine Seminarphase abgehalten, in
der sich jeder der Teilnehmer in ein projektrelevantes Thema einarbeiten sollte. Die Themen
lieÿen sich grob in fünf Bereiche klassizieren. Im ersten Bereich stand die Klärung
des Begris Web-Projekt sowie die Planung solcher Projekte im Vordergrund. Daran
schlossen sich Themen des Software Engineering an, die sich mit Architekturdesign und
Fragestellungen des Entwurfs und der Implementierungsphase auseinander setzten. Eine
Einführung in Portlets und Portale schlug dann die Brücke zum Portlet-Standard und
zur Portal-Plattform Liferay. Der vierte Block nahm sich der Aufgaben und Formen von
digitalen Bibliotheken an und der letzte Block beschäftigte sich schlieÿlich mit Metadaten
und Metadatenstandards (siehe Teil I). Die jeweiligen Ergebnisse galt es aufbereitet und
mittels einer 15-minütigen Präsentation den anderen Gruppenmitgliedern vorzustellen.
Auf diese Weise fand arbeitsteilig eine schnelle Einarbeitung in relevante Themen stand
genauso wie sich für jedes Thema ein Experte im Sinne eines Ansprechpartners herauskristallisierte.
Positiv an dieser Phase war auch, dass noch mal jeder einzelne üben konnte,
wie man aus minimalen Literaturvorgaben die für das Projekt wichtigen Zusammenhänge
heraus arbeitet und so präsentiert, dass die Zuhörer die wesentlichen Dinge begreifen und
sich ggf. vertiefend dafür interessieren.
19.2.3. Erstellung des Kriterienkatalogs
Parallel zur Seminarphase fanden erste Überlegungen hinsichtlich möglicher Anforderungen
an Bibliotheksdienste statt. Auf der Basis von Recherchen und Begutachtungen anderer
Bibliotheksangebote im Web entstand so ein Kriterienkatalog, der eine thematisch
sinnvoll geordnete und nach Relevanz gewichtete Sammlung von Merkmalen enthielt. Anhand
dieses Kriterienkatalogs wurden einige Bibliotheksdienste exemplarisch bewertet, so
dass sich für jeden Themenschwerpunkt ein Referenzsystem ergab (siehe Kapitel 14). Die
Erstellung des Kriterienkatalogs und die Arbeit damit sorgten dafür, dass sich jeder in der
Gruppe mit verschiedenen bestehenden Diensten auseinandersetzte und durch die Fragen
nach Was ist gut? und Was könnte besser sein? eine konkretere Vorstellung davon bekam,
wie ein zukünftiges System aussehen könnte. Den meisten in der Gruppe kam diese
Phase zunächst als zu lang oder zu unbedeutend vor. Doch im Nachhinein hat die Arbeit
mit dem Kriterienkatalog die einzelnen Teilnehmer sehr für die Güte von Bibliotheksdiensten
sensibilisiert. Erst so konnten viele Stärken, aber auch Schwachpunkte, anderer
Bibliotheksdienste ausgemacht werden und in die eigenen Überlegungen einieÿen.
274

19.2. ERFAHRUNGSBERICHTE
19.2.4. Anforderungsdenition
Der Übergang von der Auswertung des Kriterienkatalogs zur Denition von Anforderungen
an das zu entwickelnde Websystem verlief ieÿend. Die Ergebnisse des Katalogs ossen
direkt in die Überlegungen zu den eigenen Diensten hinein. Insbesondere der bislang
genutzte Web-Auftritt des ORBIS-Systems wurde begutachtet, da eine Integration des
ORBIS-Systems in unseren Bibliotheksdienst die elementare Aufgabe des Projekts darstellte.
Die Analyse der entsprechenden Bewertungen des Kriterienkatalogs hat zahlreiche
Schwachstellen aufgezeigt, die es nun unsererseits zu beheben galt.
Zentraler Bestandteil der Anforderungsdenition waren die Anwendungsfälle, die der zu
entwickelnde Bibliotheksdienst möglich machen sollte. Oft war die Versuchung groÿ, schon
viele Dinge im Detail zu planen. Aber gerade ein hohes Maÿ an Unsicherheit, was überhaupt
technisch möglich sei, lieÿen exaktere Denitionen der Anforderungen nicht zu. Keiner
konnte zu diesem Zeitpunkt sagen, welche Funktionen über die ORBIS-Schnittstelle
möglich wären geschweige denn über die Schnittstellen anderer zu integrierender Bibliotheksdienste.
Je mehr Bibliotheken man integrieren möchte, desto geringer wird der
Funktionskonsens, der sicher über alle Dienste angeboten werden könnte. Allerdings sollte
eine Nutzung möglichst vieler Funktionen von ORBIS ermöglicht werden.
Mit diesen Vorbedingungen im Hinterkopf wurden die Anwendungsfälle möglichst genau
speziziert. Die Summe aller Funktionen, die aus diesen Anwendungsfällen resultierten,
bildeten die Denition der funktionalen Anforderungen an das zu erstellende System. Als
weitere Bestandteile der Anforderungsdenition wurden die nichtfunktionalen Anforderungen,
der Systemeinsatz und die Zielumgebung, die Benutzungsoberäche, das Verhalten
im Fehlerfall, die Anforderungen an die Dokumentation und die Akzeptanzkriterien
speziziert (siehe Kapitel 15).
Vergleicht man nun im Nachhinein die Anforderungsdenition mit dem fertigen Produkt,
so lässt sich erkennen, dass die meisten der angestrebten Funktionalitäten vom entwickelten
System in vollem Umfang oder zumindest zu groÿen Teilen erfüllt werden. Es konnten
allerdings nicht alle erstellten Anwendungsfälle integriert werden, da die uns zugänglichen
Schnittstellen dieses nicht erlaubten. An dieser Stelle wäre es wichtig gewesen, dass die
Gruppe sich vor dieser Phase des Projekts eingängig über das ORBIS-System und seine
Schnittstelle informiert hätte bzw. informiert worden wäre. Hier ist einiges versäumt
worden.
Die Schreiben der einzelnen Kapitel und Punkte der Anforderungsdenition wurde einzelnen
Gruppenmitgliedern zugewiesen, was zur Folge hatte, dass z. B. die Denition von
Anwendungsfällen und deren genauere Funktionen von einer Person übernommen wurde.
Dieses Manko wurde aber dadurch ausgeglichen, dass die verschiedenen Punkte in den
Sitzungen mit allen diskutiert wurden und das Dokument von Sitzung zu Sitzung gereift
ist.
19.2.5. Entwurf
Die nächste Projektphase hatte den Entwurf der zu entwickelnden Bibliotheksdienste
auf der Basis der denierten Anforderungen zum Thema. Hauptaufgaben dieser Phase
sind das Erstellen einer System- und Softwarearchitektur, die die anfallenden Aufgaben
bestmöglich zu lösen im Stande ist, und das Finden von Technologien und Modellen, die
für jede Architekturschicht am adäquatesten erscheint.
275

KAPITEL 19. ZUSAMMENFASSUNG UND BEWERTUNG
Die Thematik, die einzusetzenden Technologien und die Systemumgebung selbst das
Liferay-Portal waren für alle Teilnehmer der Projektgruppe im hohen Umfang neu, so
dass diese Entwurfsphase mit zahlreichen Tests einher ging. Viele Ideen und Ansätze
angefangen von elementaren Entscheidungen hinsichtlich der Architektur bis hin zu einfachen
Fragen über die Möglichkeiten der Kommunikation zwischen Portlets galt es zunächst
konkret auszuprobieren, bevor ein Beschluss über die Umsetzbarkeit gemacht werden
konnte. So wurden innerhalb dieser Phase immer wieder kleinere Proof-Of-Concepts
entwickelt, die fundierte Rückschlüsse über einzelne Verfahren und Technologien erlaubten.
Genauso wurde ein vollständiger Prototyp implementiert, der alle vorgesehenen Architekturschichten
berücksichtigte, und somit das erfolgreiche Zusammenspiel verschiedener
Ansätze demonstrieren konnte. Auf diese Weise wuchs mit der Zeit eine immer komplexere
Architektur heran, für die in den einzelnen Schichten die Komponenten und Technologien
festgelegt werden konnten.
Das Entwurfsdokument selbst beginnt nach einer kurzen Einleitung mit einer detaillierten
Beschreibung der entwickelten Architektur. Daran anschlieÿend folgt der Entwurf der
einzelnen Schichten und Bereiche Suchlogik, Mediator / Wrapper, Benutzerkonto und
Benutzungsoberäche der jeweils konkret auf berücksichtigte Technologien und Modelle
eingeht und eine Beschreibung der Klassen und Dynamik vornimmt. Der Entwurf endet
mit einigen Erläuterungen zur Datenbankmodellierung und einer Festlegung des Testablaufs
(siehe Kapitel 16).
Zur Bearbeitung dieser einzelnen Schichten und Bereiche wurden vier Untergruppen gebildet,
die zwischen zwei und vier Personen stark waren. Diese Gruppen sollten bis zum
Ende des Projekts für alle noch anstehenden Projektphasen bestehen bleiben. Das hat den
klaren Vorteil, dass sich nicht jeder um alles kümmern und alles wissen muss. Vielmehr
kann jeder sein bisher im Studium erworbenes Wissen gewinnbringend in einem speziellen
Bereich einbringen und zusätzlich von den anderen lernen. Die Gruppen entstanden nach
persönlichen Präferenzen und Fähigkeiten. Auf diese Weise kam es zu sehr ausgeglichenen
Gruppen und programmierschwächere konnten von besseren Programmierern aufgefangen
werden und zudem von ihnen lernen.
Die Entwurfsphase war die längste Phase des Projekts. Immer wieder wurden Deadlines
nicht eingehalten oder nach hinten verschoben. Das ist sicherlich damit zu begründen, dass
es nicht einfach ist, in einem Team von zwölf Leuten eektiv zu arbeiten besonders
dann nicht, wenn jeder zu anderen Tageszeiten zur Verfügung steht und die Arbeitszeit
durch Klausuren, Übungen, Nebenjobs oder andere Verpichtungen reduziert wird. Diese
üblichen Probleme der Gruppendynamik sind aber durchaus nicht alleine als Ursache
dafür anzusehen. Dazu kommt die sehr hohe Komplexität der einzelnen Aufgaben sowie
des Projekts an sich. Es gab viele neue Technologien und Standards, die es zu erlernen
und einzusetzen galt und genauso viele zu berücksichtigende Schnittstellen sowohl nach
auÿen hin zu den einzelnen Bibliotheksdiensten, als auch intern zwischen den Schichten
der Architektur.
Trotz aller Schwierigkeiten während der Entwurfsphase ist das Ergebnis das Entwurfsdokument
auf der einen Seite und der Prototyp auf der anderen Seite sehr detailliert
ausgefallen und damit ein groÿer Schritt zur anschlieÿenden Phase des Projekts gewesen
der Implementierung der Bibliotheksdienste.
276

19.3. BEWERTUNG UND AUSBLICK
19.2.6. Implementierung
Bedingt durch die sehr lange Entwurfsphase blieb für die tatsächliche Implementierung
der entworfenen Funktionalitäten weit weniger Zeit als vorgesehen. Verglichen mit den
vorhergehenden Phasen gehörte sie zu den kürzesten. Aber es zeigte sich, dass unsere
Gruppe unter Zeitdruck am besten arbeiten kann. Eingeläutet wurde die heiÿe Implementierungsphase
mit der Durchführung eines so genannten Code-Camps. Davor verliefen
die Implementierungen eher vereinzelt und unkoordiniert. Doch mit zunehmenden Termindruck
wuchs die Einsicht zu rigoroseren Methoden die Idee des Code-Camps war
geboren.
Die Idee dahinter war, dass sich die komplette Projektgruppe über einen längeren Zeitraum
gemeinsam zusammensetzt, von der Umwelt abschottet und zusammen im Team
mindestens so lange programmiert, bis die gröÿten Brocken aus dem Weg geschat worden
sind. Also traf sich der Groÿteil der Projektgruppe im Keller des Studentenwohnheims
in der Huntemannstraÿe. Dort wurde nun eine Woche lang jeden Tag von 15 bis 6 Uhr
mit teilweise wechselnder Besetzung eiÿig entwickelt. Das Ergebnis war hervorragend.
Es wurde überall sehr viel geschat. Viele aufkommende Probleme lieÿen sich im direkten
Gespräch lösen besonders diejenigen die schicht- und schnittstellenübergreifend waren.
Das befürchtete gegenseitige Ablenken und von der Arbeit abhalten, blieb aus im Gegenteil:
Fertig gewordene Funktionen, neu angebundene Bibliotheken oder die Umsetzung
des Ganzen in ein ansprechendes Design hat alle gleichermaÿen beügelt. Wenn vorher
die ein oder andere Mail mit Arbeitsaufträgen nicht beachtet worden war, so war das
Abschlagen einer direkten Bitte während dieser Tage nicht möglich man bekam die
Hilfe genau dann, wenn man sie brauchte.
Aufgrund des Erfolg des Code-Camps hatten wir beschlossen, dass wir das Ganze auch
die letzten vier verbleibenden Wochen noch weiterführen wollen nur eben virtuell per
Chat. Auch das hat sehr gut funktioniert, da zu jeder Zeit mindestens ein Drittel der
Teilnehmer dort zur Verfügung stand.
Auch wenn die Zeit während der Implementierung die mit Abstand stressigste Zeit war,
so war sie doch zugleich auch die schönste. Erst jetzt lernte man sich so richtig kennen
besonders im Code-Camp. Man lernte, wie andere arbeiten wie andere Probleme
lösen. Und man lernte wirklich im Team zu arbeiten. Oft galt es eigene Arbeiten zur Seite
zu legen, um bei der Lösung akuterer Probleme der anderen mitzuhelfen. Jeder einzelne
bekam durch den Dialog mit den anderen einen Überblick über das ganze System.
Letztendlich haben wir es trotz der kurzen Zeit geschat, alle uns selbst auferlegten Anforderungen,
deren Realisierung technisch möglich war, zu erfüllen (siehe Kapitel 17). Die
entwickelten Dienste in Form von Portlets fügen sich nahtlos in die Umgebung das Portal
ein und bereichern es durch Layout und Funktionalität. Es war ein langer Weg vom
ersten Gruppentreen vor einem Jahr bis zur fertigen Software auf den wir alle mit sehr
viel Stolz zurückblicken.
19.3. Bewertung und Ausblick
Wir konzentrierten uns während des Projektverlaufs auf eine modulare und gut erweiterbare
Entwicklung eines Bibliothekssystems.
Damit ergaben sich folgende Schwerpunkte:
277

KAPITEL 19. ZUSAMMENFASSUNG UND BEWERTUNG
• Anbindung verschiedener Bibliotheken an den Bibliotheksdienst
• Gestaltung einer einfachen und erweiterbaren Suche
• Einbinden des BIS-Benutzerkontos in das Portal-Benutzerkonto.
Der Punkt erweiterbar wird besonders deutlich, wenn es darum geht, eine Vielzahl von
verschiedenen Bibliotheken an das System anzuschlieÿen. Bereits jetzt wurden sechs exemplarische
Bibliotheken in das System eingebunden. Um neue einzubauen braucht man
nur die bestehenden Anbindungen realisiert als Wrapper als Vorbild zu nehmen.
Ebenfalls zufrieden sind wir mit der Gestaltung der einfachen und erweiterten Suche.
Dazu muss allerdings erwähnt werden, dass wir gerne mehr Einstellungsmöglichkeiten in
die erweiterten Suche integriert hätten.
Darunter fallen zum Beispiel
• die Suche nach bestimmten Medientypen,
• die Aufteilung des ORBIS-Kataloges in Uhlhornsweg, Wechloy, Fachhochschule und
Landesbibliothek,
• die Wählbarkeit des Buchstatus von ausleihbar bis nach Absprache,
• oder die Wahl der Sprache, in der das Buch verfasst wurde.
Leider waren wir da auf die Grenzen des von uns Machbaren gestoÿen. Denn bei allen
möglichen Features sind wir abhängig von dem, was die verschiedenen Bibliotheken uns
innerhalb ihrer Schnittstellen anbieten. Daher ist das Feld erweiterbare Suche noch stark
ausbaufähig aber nur in Absprache mit den verschiedenen Bibliotheken und deren
Schnittstellen.
Sehr enttäuschend war für uns der Versuch der Einbindung des BIS-Benutzerkontos. Wir
wollten dem Benutzer ermöglichen auf die Bibliotheksfunktionen, wie Verlängerung, Vormerkung
und Löschen der Vormerkung, auch aus dem Portal heraus zu zugreifen. Leider
mussten wir davon absehen, da ein aktiver Zugri des Portals auf die Dokumente, von
seiten des BIS über die von uns verwendete Schnittstelle noch nicht realisiert ist. Also ist
es dem Benutzer bisher ausschlieÿlich möglich, sich über seine Dokumente zu informieren,
ob zum Beispiel Mahngebühren fällig sind oder Vormerkungen bestehen.
Man kann insofern sagen, dass wir unsere Ziele erreicht haben und die Schwerpunkte
erfolgreich umgesetzt haben. Auch wenn wir bei einigen Features Zugeständnisse an die
Realität und die Grenzen unseres Einusses machen mussten.
Während der Arbeit sind uns natürlich immer wieder neue benutzerfreundliche Methoden
eingefallen, um den Benutzern einen gröÿeren Service anzubieten. Wie wäre zum Beispiel
die Integration eines Lesezeichenportlets? Es hätte eine ähnliche Funktion wie ein Warenkorb
in einem eShop oder einer Wunschliste ähnlich wie bei Amazon und könnte auch den
Export von Literaturlisten für Bachelor- oder Masterarbeiten in BibTex- oder Endnote-
Format anbieten. Natürlich darf man auch nicht den Livechat des BIS-Servicebereich
auÿer Acht lassen. Solche und weitere Punkte wären gute Ergänzungen unseres Bibliotheksdienstes.
Diese oder ähnliche Features einzubauen wäre unser nächstes Ziel.
Es ist uns klar, dass unser System noch ein paar Tuningmöglichkeiten oen lässt. Daher
kamen wir in Absprache mit der BIS überein, eine Testphase innerhalb der Zentralbibliothek
Uhlhornsweg durchzuführen. Es ist in Planung ein paar Terminals mit unserem
278

19.4. DANKSAGUNGEN
Bibliotheksdienst in der Bibliothek aufzustellen, um so zu erfahren wie unsere Arbeit
von den Benutzern bewertet wird. Dadurch können wieder neue Ideen entstehen, die das
Bibliothekssystem noch attraktiver machen könnten.
19.4. Danksagungen
Ein Dank geht an die Mitarbeiter der EDV-Abteilung der Universitätsbibliothek Oldenburg,
die viel Zeit und Geduld für unsere Fragen und groÿes Entgegenkommen bei unseren
Wünschen gezeigt haben.
Ein besonderer Dank geht natürlich an unsere Betreuer, die unsere Arbeit mit viel Geduld,
Wohlwollen und unerschütterlichem Glauben an unsere Fähigkeiten begleitet haben.
279

Teil III.
Anhang
281

A. Inhalt der DVD
Dieses Kapitel gibt einen Überblick über den Inhalt und den strukturellen Aufbau der
zum Endbericht gehörenden DVD. Sie beinhaltet alle im Rahmen des Projekts erstellten
und entstandenen Dokumente und Ergebnisse. Eine detaillierte Beschreibung der Ordnerstruktur
und der Inhalte des Datenträgers wird im folgenden vorgenommen.
• Binaries: In diesem Ordner bendet sich der im Rahmen des Projekts entwickelte,
auf Portlets basierende Bibliotheksdienst bestehend aus den sich an dieser Stelle
bendenen JAR-, WAR und SAR-Archiven. Diese können einfach im Applikationsserver
des Liferay Portals deployed und zur Ausführung gebracht werden.
• Dokumente: Dieser Ordner enthält alle während des Projekts entstandenen Dokumente.
Ergebnisdokumente der Softwareentwicklung: Dieser Ordner enthält die
im Rahmen der Projektgruppe erstellten Dokumente zur Dokumentation des
Entwicklungsprozesses. Das Kerndokument stellt hier der Endbericht dar. Aber
auch die Ergebnisanalyse der untersuchten Bibliotheksdienste, die Anforderungsdenition,
der Entwurf oder das Benutzerhandbuch sind hier zu nden.
Java-Dokumentation: An dieser Stelle bendet sich die Dokumentation des
Source-Codes (JavaDoc).
Protokolle: Hier sind die Protokolle der einzelnen Sitzungen zu nden.
Seminarausarbeitungen: Dieser Ordner enthält die jeweiligen Ausarbeitungen
zu den gehaltenen Seminaren.
Seminarvorträge: Die Foliensätze zu den gehaltenen Präsentationen benden
sich in diesem Ordner
• Entwicklungswerkzeuge: An dieser Stelle können einige freie Entwicklungswerkzeuge
gefunden werden, die die Projektgruppe zur Entwicklung und Implementierung
der Bibliotheksdienste genutzt hat.
Eclipse: Die freie IDE für Java in der Version 3.1.2 neben einigen nützlichen
Plugins.
Liferay 3.6.1: Die Liferay Portalsoftware in der Version 3.6.1. Die entwickelten
Portlets sind auf diesem System implementiert und getestet worden.
Im Projekt wurde die Konguration mit dem integrierten JBoss Applikationsserver
und dem Tomcat-Webserver verwendet.
Standalone JBoss: Der Standalone JBoss Applikationsserver in der Version
4.0.3.
Versionsverwaltung: Ein Versionsverwaltungswerkzeug auf SVN-Basis für
Windows-Betriebsysteme: TortoiseSVN in der Version 1.2.1.
283

ANHANG A. INHALT DER DVD
• Repository: In diesem Ordner bendet sich das vollständige SVN-Repository, wie
es von der Projektgruppe zur parallelen Entwicklung der Software und der Pege der
Dokumentation genutzt worden ist. Das SVN-Repository hat die folgende Struktur:
code: Dieser Ordner beinhaltet den kompletten Source-Code des Projekts geordnet
nach Modulen und Paketen. Ebenso sind hier die Code-Bibliotheken
(libs) oder diverse Kompilier- und Deploy-Skripte zu nden.
dokumente: In diesem Ordner wurden alle während des Projekts entstandenen
Dokumente abgelegt und gepegt. Dazu zählen neben Anforderungsdenition,
Entwurf und Endbericht auch sämtliche Protokolle, Seminarausarbeitungen
und Foliensätze sowie die Dokumentation des Javacodes (JavaDoc).
fertige dokumente: Dieser Ordner enthält die Final-Versionen der im Rahmen
der Projektgruppe erstellten Dokumente. Das Kerndokument stellt hier
der Endbericht dar. Aber auch die Ergebnisanalyse der untersuchten Bibliotheksdienste,
die Anforderungsdenition, der Entwurf oder das Benutzerhandbuch
sind hier zu nden.
legacy: In diesem Ordner sind Zwischenergebnisse für Präsentationen, Beispiele
für Technologien oder angefertigte Proof Of Concepts zu nden.
vorlagen: Im Ordner vorlagen benden sich Latex-Vorlagen für gruppeninterne
Dokumente, wie Protokolle oder Seminarausarbeitungen.
zeug: Dieser Ordner dient zur Speicherung oder zur Verfügungstellung von Dokumenten
und Dateien, die thematisch nicht den anderen Kategorien / Ordnern
zugeordnet werden können.
284

B. Das Departmentfussballturnier
2005
Damit sich alle Mitstreiter der Projektgruppe untereinander besser kennenlernen können,
haben wir uns sehr schnell und einstimmig dazu entschlossen, am alljährig stattnden
Fussballturnier der Projektgruppen teilzunehmen. Leider sind Informatiker in der Regel
nicht die aller sportlichsten Menschen auf der Welt, so dass das ein oder andere Training
im Vorfeld ja nicht schaden konnte. So fand sich schon Wochen vor dem eigentlichen
Turnier der harte Kern zu Trainingssitzungen zusammen jeweils im Anschluss an die
regelmässigen Gruppentreen. Im Normalfall dauerte so eine Sitzung 90 Minuten, was den
ein oder anderen aus unseren Reihen durchaus an seine Grenzen bringen sollte. Allerdings
stellte sich schnell heraus, dass wir mit zwei Ballzauberern gesegnet waren Ahmed und
Ling. Aber auch wir anderen wussten sehr schnell mit dem runden Leder umzugehen.
Man lernte sich mit jedem Mal besser kennen und schon bald verstand man sich nahezu
blind nicht nur auf dem Platz. Die Zuversicht stieg mit jedem Training.
Dann war es soweit der 17.08.2005 um 14:00 Uhr auf dem Sportplatz an der Haareneschstraÿe
das Turnier begann. Neun wackere Spieler (siehe Mannschaftsfoto: B.1) mit
dem Turniersieg vor Augen betraten das Spielfeld, um die Früchte der harten Arbeit zu
ernten.
Im folgenden der Originalbericht von Ahmed direkt noch am selben Abend voller
Euphorie verfasst und per eMail an die Projektgruppe versand. So konnten auch diejenigen
etwas von dem Feuer und dem Elan spüren, die leider nicht am Turnier teilnehmen
konnten.
Erstmal das Wichtigste: Wir sind 4. geworden von 15 Teams. Damit sind wir
sehr zufrieden. Am Ende fehlte uns die Puste.
Hier ein paar Highlights:
Durch Hermanns Torwartparaden gingen wir ohne Gegentor aus den Gruppenspielen
hervor.
Wir erlangten sogar den ersten Platz in der Gruppe. Und das durch das Tor
von Timo in der letzten Minute im letzten Spiel. So hatten wir eine bessere
Tordierenz als der Konkurrent.
Gruppenspielergebnisse: 1:0, 0:0, 4:0!
Im Viertelnale gewannen wir erst nach einem Elfmeterkrimi. Nachdem fast
alle angetreten waren, verwandelte Miriam ihren Elfmeter souverän zum Sieg.
Im Halbnale wollten dann unsere Lungen nicht mehr. So verloren wir verdient
3:0, obwohl die Tore sehr unglücklich entstanden. Beim Spiel um Platz 3 gingen
wir schon auf dem Zahneisch. Aber trotzdem hätten wir auch das Spiel für uns
entscheiden können. Leider fehlte am Ende das Quäntchen Glück. So verloren
wir das Spiel ebenfalls. Das 1:0 von unserem Gegner war ärgerlich. Aber es
285

ANHANG B. DAS DEPARTMENTFUSSBALLTURNIER 2005
hat unsere Laune nicht verdorben. Danach hatten wir noch ein erfolgreiches
Ausschwitzen mit einigen Energy-Drinks (Becks war das glaube ich).
Das schönste Tor schoss wohl Ling. Er eroberte den Ball am eigenen Strafraum
und lieÿ sich dann nicht mehr aufhalten. Er schoss eigentlich gar nicht ins
Tor, sondern er trieb den Ball ins selbige. Er hatte so ein Tempo drauf, da
konnte er nur noch vom Netz aufgehalten werden. Die Gegner hatten nur einen
Lufthauch gespürt von ihm. Ich glaub, die stehen da immer noch und suchen
ihn.
Danke, hat Spaÿ gemacht. Und nächstes Mal holen wir uns den Pokal.
Leider konnten nicht alle PG-Mitglieder am Turnier teilnehmen, da es mitten in den Semesterferien
stattfand. Aber es haben sich am Tag der Entscheidung immerhin 9 Helden
zusammengefunden, um auÿergewöhnliches zu vollbringen. Abbildung B.1 zeigt ein Gruppenfoto
dieser legendären Mannschaft. Darauf fehlt unser Betreuer Jürgen Sauer, der nach
der erfolgreich absolvierten Vorrunde leider noch andere Termine wahrnehmen musste.
Abbildung B.1.: Die Helden des Tages
Obere Reihe: Timo Bernack, Timo Albrecht, Michael Riehemann, Hermann
Schulte-Borchers, Miriam Wol, Ling Zou
Untere Reihe: Ahmed Yousse, Alexander Duscheleit (von links nach rechts)
286

C. Glossar
Account
Ein Account ist in einem Onlinedienst eine Einrichtung, die dazu dient, den Benutzer
zu identizieren und dessen Aktivitäten zum Zweck der Abrechnung zu protokollieren.
In diesem Zusammenhang wird Account (wörtlich übersetzt: Konto, Guthaben)
auch als Benutzerkonto bezeichnet.In lokalen Netzwerken und Mehrbenutzer-
Betriebssystemen stellt der Account eine vergleichbare Einrichtung dar. Da die Benutzung
jedoch in der Regel nicht mit Kosten verbunden ist, wird der Account dort zum
Zweck der Identikation, Verwaltung und Sicherheit angelegt, nicht aber zur Abrechnung.
Akteur
Es ist der Akteur, der einen Anwendungsfall anstöÿt oder der die erwarteten Resultate
eines Anwendungfalls entgegennimmt. Akteure sollten jedoch nicht mit konkreten handelnden
Personen oder Systemen verwechselt werden. Ein Akteur ist eher als eine Art
Rolle zu betrachten. Kundenberater ist zum Beispiel als Name für einen Akteur weit
wahrscheinlicher als Hans Meier vom Verkauf.
Authentizierung
Authentizierung bezeichnet den Vorgang, die eindeutige Identität einer Person anhand
eines bestimmten Merkmals zu überprüfen.
Benutzerkonto
Ein Benutzerkonto ist auf einem Sicherheits- oder Mehrbenutzersystem eine Einrichtung,
die einer Einzelperson den Zugri auf ein System und seine Ressourcen ermöglicht.
Ein Benutzerkonto wird im Allgemeinen durch den Systemverwalter eingerichtet und
enthält Angaben über den Benutzer (wie Kennwort, Rechte und Befugnisse).
Branding
Branding stammt vom englischen Wortstamm to brand ab. Es geht um die Kennzeichnung
eines Produktes oder einer Dienstleistung als Marke durch Bild, Wort- und
Namenszeichen, Markenzeichen, Warenzeichen und Gütezeichen.
Connector/J
Connector ist der Name des JDBC-Treibers für das quelloene Datenbankmanagementsystem
MySQL. Der Treiber liegt als JAR-Archiv vor und unterstützt die JDBC 3.0
Spezikation.
http://www.mysql.com/products/connector/j/
Content (Inhalte)
Content umfasst alle zur Informationsvermittlung einer Web-Anwendung erforderlichen
Inhalte (Daten, Texte, Bilder, Videos etc.) und ist zu unterscheiden von Elementen zur
Präsentation und Navigation.
Datenbankmanagementsystem (DBMS)
Ein Datenbankmanagementsystem ist je nach nicht immer ganz einheitlicher Begris-
287

ANHANG C. GLOSSAR
denition Teil eines übergeordneten Datenbank- oder auch Informationssystems und
dort zuständig für die Datenhaltung und die Denition des Datenmodells.
Datenbanksystem (DBS)
Ein Datenbanksystem ist ein einfaches Informationssystem, das aus Datenbanken und
einem Datenbankmanagementssystem (DBMS) gebildet wird.
Data Denition Language (DDL)
Mit Data Denition Language ist eine Untermenge der Datenbankabfragesprache SQL
gemeint, mit der der Aufbau der Datenbank, d.h. (in einem relationalen DBMS) die
konkrete Tabellenstruktur, festgelegt wird.
Digitale Bibliothek
Eine Digitale Bibliothek bietet Literaturinformationen und Literatur elektronisch über
das Internet.
Drei-Schichten-Architektur
Bei der Drei-Schichten-Architektur (oder Model-View-Controller-Modell, kurz MVC-
Modell) handelt es sich um ein Architekturmuster zur Trennung eines Programms in die
drei Einheiten Datenmodell (engl. Model), Präsentation (engl. View) und Programmsteuerung
(engl. Controller). Ziel des Modells ist ein exibles Programmdesign, um u.a.
eine spätere Änderung oder Erweiterung einfach zu halten und die Wiederverwendbarkeit
der einzelnen Komponenten zu ermöglichen. Auÿerdem sorgt das Modell bei
groÿen Anwendungen für eine gewisse Übersicht und Ordnung durch Reduzierung der
Komplexität.
Enterprise Java Beans (EJB)
Enterprise Java Beans ist eine standardisierte Komponente in der Programmiersprache
Java. Sie ermöglicht Softwareentwicklern, Java-Technologie für die Erstellung wiederverwendbarer
Serverkomponenten für geschäftliche Anwendungen einzusetzen. EJB ist
Teil von J2EE.
http://java.sun.com/products/ejb/
eXtensible Markup Language (XML)
XML ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente fürs
Internet. XML erlaubt im Gegensatz zu HTML nicht nur eine strukturelle Beschreibung
eines Textes, sondern auch eine inhaltliche Klassizierung von Informationen sowie die
Denition beliebiger neuer eigener Elemente. Mit XML-Browsern ist dann die individuelle
Darstellung von XML-Seiten für verschiedene Nutzergruppen möglich.
http://www.w3.org/TR/2004/REC-xml11-20040204/
eXtensible Stylesheet Language Transformations (XSLT)
XSLT ist eine Sprache zur Transformation eines XML-Dokuments in ein anderes XML-
Dokument oder in ein anderes Format, wie z. B. PDF.
http://www.w3.org/TR/1999/REC-xslt-19991116/
Entity-Relationship-Diagramm (ER-Diagramm)
Ein ER-Diagramm ist eine im Jahre 1976 entwickelte grasche Notation zur statischen
Modellierung eines Systems. Man unterscheidet zwischen Entitäten und Beziehungen.
Hibernate
Hibernate ist ein quelloenes Persistenz-Framework für Java. Ermöglicht O/R-Mapping,
d.h. die Zuordnung von Java-Objektdaten zu in einem DBMS abgelegten Tabellen.
http://www.hibernate.org/
288

Hypertext Markup Language (HTML)
Hypertext Markup Language ist eine Beschreibungssprache (language), mit der man
Texte, die Querverweise enthalten (hypertext), mithilfe eingestreuter Markierungssymbole
(markups) in Seiten aufteilen und die Einzelteile des Textes genau spezizieren
kann. Mit HTML werden die Dokumente im Internet dargestellt, so dass sie von Browsern
in gewünschter Weise angezeigt werden können.
http://www.w3.org/MarkUp/
Hypertext Transfer Protocol (HTTP)
Der Hypertext Transfer Protocol deniert den Zugri von Clients, z. B. Webbrowsern,
auf serverseitig gespeicherte Informationen im World Wide Web.
http://www.faqs.org/rfcs/rfc2616.html
Identity Management System
Unter Identity-Management versteht man die Verwaltung von Entitäten (Personen oder
Dinge) in einem Unternehmen oder einer Behörde. Ziel ist es, den Vorgang des Zuordnes
von systemweit eindeutigen Identikatoren zu einer die Entität beschreibenden Attributen,
wie etwa den Namen, so selten wie möglich (am besten nur ein einziges Mal)
durchzuführen.
Informationssystem
Ein Informationssystem dient der rechnergestützten Erfassung, Speicherung, Verarbeitung,
Pege, Analyse, Benutzung, Verbreitung, Disposition, Übertragung und Anzeige
von Information.
Java 2 Enterprise Edition (J2EE)
Java 2 Platform, Enterprise Edition ist die Spezikation einer Standardarchitektur
für die Ausführung von Anwendungskomponenten unter Federführung der Firma Sun
Microsystems. Bestandteile der Spezikation werden innerhalb des Java Community
Process von diversen Unternehmen erarbeitet und schlieÿlich der Öentlichkeit in Form
eines Dokuments und einer Referenzimplementierung zur Verfügung gestellt. Mittlerweile
wurde der Name in Java Platform, Enterprise Edition (Java EE) geändert.
http://java.sun.com/javaee/index.jsp
Javadoc
Javadoc ist ein Software-Dokumentationswerkzeug, das aus Java-Quelltexten automatisch
Dokumentationsdateien erstellt.
http://java.sun.com/j2se/javadoc/
JavaScript
JavaScript ist eine objektbasierte, clientseitig ausgeführte Skriptsprache, die von der
Firma Netscape entwickelt wurde, um statische HTML-Seiten dynamisch zu gestalten.
Java
Java ist ein von Sun Microsystems entwickelte objektorientierte Programmiersprache.
Das Konzept von Java ist sehr sicher und plattformneutral (d. h. Java kann auf jedem
Betriebssystem ausgeführt werden). Wurde gezielt für das Internet entwickelt.
http://www.java.com
JBoss
JBoss Inc. ist eine Firma, deren Hauptprojekt die Implementierung eines J2EE-konformen
Applikations-Servers ist. Zumeist wird aber auch der Applikations-Server selbst mit
JBoss bezeichnet. Wenn der Kontext nicht eindeutig ist, ist die Bezeichnung JBoss
289

ANHANG C. GLOSSAR
AS, der ozielle Name des Produkts, präziser.
http://www.jboss.com/products/jbossas
Java Community Process (JCP)
Bei Java Community Process handelt es sich um ein Standardisierungskomitee, das sich
speziell der Weiterentwicklung der Programmiersprache Java widmet. Der JCP erzeugt
die JSRs, wobei nach einem Organisationsablauf vorgegangen wird, der seinerseits in
einem JSR deniert ist (JSR 215).
http://www.jcp.org/en/home/index
Java Database Connectivity (JDBC)
Java Database Connectivity ist eine API-Spezikation der Java-Plattform, die eine einheitliche
Schnittstelle zu Datenbanken verschiedener Hersteller bietet und speziell auf
relationale Datenbanken ausgerichtet ist.
http://java.sun.com/products/jdbc/
Java Message Service (JMS)
Java Message Service ist eine API der Firma Sun Microsystems für den Austausch
von Nachrichten zwischen zwei oder mehr Clients, die in der Programmiersprache Java
geschrieben sind.
http://java.sun.com/products/jms/
Java Open Application Server (JOnAs)
Der Java Open Application Server ist neben JBoss bis dato einziger quelloener und
lizenzkostenfreier Applikationsserver mit J2EE 1.4 Zertizierung.
http://jonas.objectweb.org/
JSR-168
JSR-168 ist eine Java Portlet Spezikation für die Kommunikation zwischen Portlet
und Portal.
http://www.jcp.org/en/jsr/detail?id=168
Java Specication Request (JSR)
Java Specication Request sind Ergebnisse des JCP in Form von versionierten Spezikationsdokumenten.
JavaServer Pages Standard Tag Library (JSTL)
Die JavaServer Pages Standard Tag Library ist eine Sammlung von vier Custom-Tag
Bibliotheken, die für die Erstellung von JSP-Seiten hilfreich sind.
http://java.sun.com/products/jsp/jstl/
JavaServer Pages (JSP)
JavaServer Pages ist eine von Sun Microsystems entwickelte Technologie, die im Wesentlichen
zur einfachen dynamischen Erzeugung von HTML- und XML-Ausgaben eines
Webservers dient. Sie erlaubt es Java-Code und spezielle JSP-Aktionen in statischen
Inhalt einzubetten. Dies hat den Vorteil, dass die Logik unabhängig vom Design implementiert
werden kann.
http://java.sun.com/products/jsp/
Liferay-Portal
Das Liferay-Portal ist ein Webbasiertes Informations-Portal und Anwendungsframework
mit zentralem Berechtigungs-Konzept.
http://www.liferay.com/web/guest/home
Lernmanagement-System (LMS)
290

Ein Lernmanagement-System, auch Learning Management System oder Lernplattform
genannt, bildet in der Regel den technischen Kern einer komplexen webbasierten E-
Learning Infrastruktur. Es handelt sich dabei um eine auf einem Webserver installierte
Software, die das Bereitstellen und die Nutzung von Lerninhalten unterstützt und Instrumente
für das kooperative Arbeiten und eine Nutzerverwaltung bereitstellt.
Lehrveranstaltungsplan (LVP)
Im Lehrveranstaltungsplan werden alle Lehrveranstaltungen an der Universität aufgeführt
mit dessen Zeiten und Raumbelegungen.
Machine-Readable Cataloguing (MARC)
Machine-Readable Cataloguing ist ein Standard für bibliographische Angaben in maschinenlesbarer
Form. Es ist die internationale Variante zum MAB.
Maschinelles Austauschformat für Bibliotheken (MAB)
Das Maschinelle Austauschformat für Bibliotheken ist ein vor allem im Deutschen Bibliothekswesen
gebräuchliches Austauschformat für Metadaten.
Message-Driven-Bean (MDB)
Message-Driven-Bean ist neben Session-Bean und Entity-Bean die dritte der EJB-
Arten. MDBs werden eingesetzt zur Verarbeitung von JMS-Nachrichten.
Metadaten
Metdadaten sind Daten, die Informationen über andere Daten enthalten.
Middleware
Middleware bezeichnet in der Informatik anwendungsunabhängige Technologien, die
Dienstleistungen zur Vermittlung zwischen Anwendungen anbieten, so dass die Komplexität
der zugrundeliegenden Applikationen und Infrastruktur verborgen wird.
MySQL
MySQL ist ein quelloenes und lizenzkostenfreies DBMS mit groÿer Verbreitung und
weitreichender Kompatibilität.
http://www.mysql.com/
Open Archives Initiative (OAI)
Die Protokolle und Standards der Open Archives Initiative dienen dazu, Informationen
und (digital verfügbare) wissenschaftliche Dokumente in einem einheitlichen Format
online zur Verfügung zu stellen.
http://www.openarchives.org/
Oldenburger Bibliotheks- und Informationssystem (BIS)
Bibliotheks- und Informationssystem über eine Kooperation von Bibliotheken aus Oldenburg.
Portal
Eine Portal-Website ist eine Zusammenstellung von Verknüpfungen, Inhalten und Diensten,
die dem Benutzer interessante Informationen bereitstellt, wie Nachrichten, Wetterberichte,
Unterhaltung, kommerzielle Sites, Chaträume usw. Yahoo und Lycos sind
Beispiele für Portal-Websites.
Portlet
Ein Portlet ist ein kleines Programm, das in der Programmiersprache Java geschrieben
ist und im Prinzip die Fähigkeiten eines Servers erweitert, in diesem Fall die eines
Portalservers. Portlets stellen dabei auf der Clientseite eine einfach zu benutzende Ober-
291

ANHANG C. GLOSSAR
äche innerhalb des Browsers dar (Fenster mit Knöpfen zum Maximieren, Minimieren,
Editieren, Hilfe). Intern, also auf Serverseite, kann nun eine beliebige Anwendung liegen,
die ihre Darstellung auf des Portlet weiterleitet.
Prototyp
Ein Prototyp ist eine ausführbare und evaluierbare Version eines Systems oder Systemteils
(evolutionärer Prototyp), um ausgewählte Merkmale des späteren, operationellen
Systems (explorativer oder experimenteller Prototyp) zu evaluieren; ein für die jeweiligen
Zwecke voll funktionsfähiges Versuchsmodell eines geplanten Produktes.
Resource Description Framework (RDF)
RDF ist eine Beschreibungssprache zur Denition von Metadaten von Ressourcen. Eine
Ressource ist jede Informationsquelle im Web, die durch eine URI eindeutig identizierbar
ist. RDF ist eine Entwicklung des World Wide Web Consortiums (W3C) und steht
frei zur Verwendung. In Verbindung mit RDF-Schema und der Web Ontology Language
(OWL) soll RDF als grundlegendes Format zur Repräsentation von Taxonomien und
Ontologien also formalen Vokabularen im Allgemeinen dienen. Der Hauptanwendungsbereich
von RDF ist das semantische Web, das eine Erweiterung des bestehenden
Webs mit maschineninterpretierbaren Inhalten darstellt.
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
Scalable Vector Graphics (SVG)
SVG ist ein Standard zur Beschreibung zweidimensionaler Vektorgraken in der XML-
Syntax.
http://www.w3.org/TR/2003/REC-SVG11-20030114/
Schnittstelle
Schnittstelle ist ein Teil eines Systems, das dem Austausch von Informationen als Spannungen,
Energie oder Materie analog oder digital mit anderen Systemen dient. Bei
einer Schnittstelle werden digitale oder auch analoge Daten übergeben. Eine Schnittstelle
wird durch eine Menge von Regeln beschrieben, der Schnittstellenbeschreibung.
Neben der Beschreibung, welche Funktionen vorhanden sind und wie sie benutzt werden,
gehört zu der Schnittstellenbeschreibung auch ein so genannter Kontrakt, der die
Semantik der einzelnen Funktionen beschreibt.
Search/Retrieve via URL (SRU)
SRU ist ein standardisiertes Protokoll für Internetsuchanfragen unter Zuhilfenahme der
CQL (Common Query Language), einer Syntax für Anfragen.
Server-Side Include (SSI)
SSI beschreibt Mechanismen, bei denen ein Webserver dynamisch Werte in eine HTML-
Seite einfügen kann, bevor die Seite an den Browser geschickt wird. Die aktuelle Systemzeit
ist ein einfaches Beispiel für ein SSI.
Simple Object Access Protocol (SOAP)
SOAP ist ein XML-basiertes Protokoll zum systemunabhängigen Austausch von Nachrichten.
Es deniert einen XML-Envelope zum Austausch von XML-Nachrichten über
verschiedene Protokolle wie HTTP, SMTP und andere.
Single-Sign-On
Single-Sign-On bedeutet, dass ein Benutzer nach einer einmaligen Authentizierung auf
alle Rechner und Dienste, für die er berechtigt ist, zugreifen kann, ohne sich jedesmal
neu anzumelden. Ein Benutzer besitzt dadurch nur eine einzige Identität, die nur einmal
292

(z.B. durch Passworteingabe) veriziert werden muss.
Structured Query Language (SQL)
Structured Query Language ist eine deklarative Abfragesprache für relationale DBMS.
Synchronized Multimedia Integration Language (SMIL)
SMIL ist ein auf XML basierender, von dem World Wide Web Consortium (W3C)
entwickelter Standard für zeitsynchronisierte, multimediale Inhalte. SMIL ermöglicht
die Einbindung und Steuerung von Multimedia-Elementen wie Audio, Video, Text und
Grak in Webseiten.
http://www.w3.org/TR/1998/REC-smil-19980615/
Tomcat
Tomcat ist eine Referenz-Implementierung der JSP-Spezikation.
http://tomcat.apache.org/
Unied Modeling Language (UML)
Unied Modeling Language (dt. vereinheitliche Modellierungssprache) dient zum einen
der Veranschaulichung und dem Dokumentieren von Ideen, Modellen, Vorgehensweisen
und Lösungen, zum anderen kann man mit ihr spezizieren und entwerfen. Dies erfolgt
vor allem mithilfe von Diagrammen.
Universal Description, Discovery, and Integration (UDDI)
UDDI ist eine technische Spezikation für die Beschreibung, Entdeckung und Integration
von Web-Services. Die so genannten White Pages enthalten allgemeine Informationen
über das Unternehmen, die Yellow Pages weitere Klassikationsdaten, basierend
auf Industriestandardtaxonomien, und die Green Pages enthalten die technischen Informationen
über die zur Verfügung gestellten Web-Services.
URICA
URICA ist ein Bibliotheksverzeichnissystem.
Use Case
Ein Use Case im Deutschen auch als Anwendungsfall bezeichnet deniert die Interaktionen
zwischen Akteuren und dem betrachteten System, die stattnden, um ein
bestimmtes fachliches Ziel zu erreichen. Anwendungsfälle beschreiben immer nur genau
einen Ablauf oder einen Geschäftsprozess.
WAI
Das WAI ist ein Unterbereich des W3C-Konsortiums, das sich mit dem barrierefreien
Zugang zum Internet und seinen Inhalten beschäftigt.
http://www.w3.org/WAI/
Web Service Description Language (WSDL)
WSDL ist eine XML-basierte Sprache zur Beschreibung eines Web-Service. Ein WSDL-
Dokument beinhaltet die Schnittstellenbeschreibung des Dienstes, Informationen über
die verwendeten Datentypen, Binding-Informationen über die verwendeten Transportprotokolle
und Adressinformationen für die Lokalisation des Dienstes.
World Wide Web Consortium (W3C)
Das World Wide Web Consortium ist das Gremium zur Standardisierung das World
Wide Web betreender Techniken. Gründer und Vorsitzender des W3C ist Tim Berners-
Lee, der auch als der Ernder des World Wide Web bekannt ist. Bei der Entwicklung
neuer Standards hat sich das W3C verpichtet, nur noch Technologien zu verwenden,
die frei von Patentgebühren sind.
293

ANHANG C. GLOSSAR
XML Path Language (XPath)
XPath ist eine vom W3C-Konsortium entwickelte Anfragesprache um Teile eines XML-
Dokumentes zu adressieren. Auf diese Weise kann eine Suche und Navigation in XML-
Dokumenten durchgeführt werden. XPath dient als Grundlage einer Reihe weiterer
Standards wie XSLT, XPointer und XQuery.
http://www.w3.org/TR/1999/REC-xpath-19991116/
Z39.50
Das Z39.50 ist ein Standard, der ein Protokoll zur Informationsbeschaung aus Datenbanken
auf der Anwendungsschicht deniert. Mit Hilfe des Protokolls ist es möglich,
mehrere Informationssysteme über eine einheitliche Schnittstelle abzufragen. Gleichzeitig
kann das jeweilige Informationssystem die Daten in unterschiedlicher Form übermitteln,
sodass es spezischen Anforderungen genügen kann.
294

D. Verzeichnisse
Abbildungsverzeichnis
2.1 Projektorganisation und Umfeld . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Phase der Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Beispiel für Mitarbeitereinsatz im Projektverlauf . . . . . . . . . . . . . . 24
2.4 Projektprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Kosten im Zusammenhang mit einem Webprojekt . . . . . . . . . . . . . 27
3.1 Variante eines Gantt-Charts . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 J2EE Enterprise Application Model . . . . . . . . . . . . . . . . . . . . . 44
4.2 Bestandteile einer Session Bean . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Session-Façade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Anforderungen an die Modellierung von Web-Anwendungen . . . . . . . . 54
5.2 Teilaufgaben des Designs von Web-Anwendungen . . . . . . . . . . . . . 57
5.3 Vorgehensweisen beim Architekturentwurf . . . . . . . . . . . . . . . . . 58
6.1 Klassisches IT-System und dessen Abhängigkeiten . . . . . . . . . . . . . 65
6.2 IT-Struktur unter Verwendung eines Portals . . . . . . . . . . . . . . . . 65
6.3 Portal Integration zwischen Clients und Informationssysteme . . . . . . . 68
7.1 Überblick der Portal-Architektur . . . . . . . . . . . . . . . . . . . . . . . 72
7.2 Beispiel einer Portal-Page auf Basis des Portals Liferay . . . . . . . . . . 74
7.3 Verzeichnisstruktur WAR-Archiv . . . . . . . . . . . . . . . . . . . . . . 76
7.4 Portal-Architektur bei Verwendung von WSRP . . . . . . . . . . . . . . . 78
7.5 Typische WSRP-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1 Liferay: Themes zur Personalisierung . . . . . . . . . . . . . . . . . . . . 81
8.2 Liferay: Sub-Themes weitere Manipulationen der Ansicht . . . . . . . . 81
8.3 Liferay: Portletfunktionen dank AJAX jetzt auch per drag-n-drop . . 82
8.4 Liferay: Dokumentennverwaltung als Portlet . . . . . . . . . . . . . . . . 82
8.5 Liferay: Image Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.6 Liferay: WYSIWYG Editor . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.7 Liferay: Lokalisiertung durch JSTL . . . . . . . . . . . . . . . . . . . . . 85
8.8 Liferay: Demployment-Matrix . . . . . . . . . . . . . . . . . . . . . . . . 86
295

Abbildungsverzeichnis
8.9 Liferay: Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9.1 Komponenten einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . . 95
10.1 Externe Einbindung einer digitalen Bibliothek . . . . . . . . . . . . . . . 106
10.2 Struktur einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . . . . . 107
11.1 5-Ebenen-Schema-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 112
11.2 Systemskizze für DL-integriertes Portal auf Basis des Mediator-Wrapper . 113
11.3 InfoBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.4 eVerlage-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.5 OMNIS/2-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.6 Der Virtuelle Dokumentenserver der BlueView-Architektur . . . . . . . . 118
11.7 DAFFODIL-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
15.1 UML Anwendungsfalldiagramm des zu entwickelnden Systems . . . . . . 160
15.2 Gesamtansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
15.3 Portlet - Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
15.4 Portlet - einfache Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
15.5 Portlet - erweiterte Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
15.6 Portlet - Ergebnisausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . 177
15.7 Portlet - Ergebnisausgabe mit Details . . . . . . . . . . . . . . . . . . . . 178
15.8 Portlet - Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
15.9 Benutzerkonto - Sucheinstellungen . . . . . . . . . . . . . . . . . . . . . . 179
15.10 Benutzerkonto - Dokumentenübersicht . . . . . . . . . . . . . . . . . . . 180
15.11 Benutzerkonto - Weitere Einstellungen . . . . . . . . . . . . . . . . . . . 181
15.12 mögliche Erweiterungsportlets . . . . . . . . . . . . . . . . . . . . . . . . 181
15.13 mögliche Erweiterung: Lesezeichen Portlet . . . . . . . . . . . . . . . . . 182
16.1 Grobarchitektur des Bibliotheksdienstes, schichtenorientierte Sicht . . . . 188
16.2 Grobarchitektur des Bibliotheksdienstes, komponentenorientierte Sicht . . 190
16.3 Sequenzdiagramm für das gesamte System . . . . . . . . . . . . . . . . . 191
16.4 Sequenzdiagramm EJB-Schicht . . . . . . . . . . . . . . . . . . . . . . . . 192
16.5 Sequenzdiagramm Mediator und Wrapper . . . . . . . . . . . . . . . . . . 193
16.6 Paketdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
16.7 Klassendiagramm der Suchlogik . . . . . . . . . . . . . . . . . . . . . . . 199
16.8 Sequenzdiagramm der Suchlogik . . . . . . . . . . . . . . . . . . . . . . . 200
16.9 Paket org.pgportal.ejb.dto: Struktur der Anfrage Objekte . . . . . . . . . 203
16.10 Paket org.pgportal.ejb.dto: Struktur der Ergebnis Objekte . . . . . . . . 204
16.11 Paket org.pgportal.ejb.wrapper : Struktur . . . . . . . . . . . . . . . . . . 207
16.12 Klassendiagramm des Benutzerkontos . . . . . . . . . . . . . . . . . . . . 211
16.13 Sequenzdiagramm: Abrufen der Einstellungen des Benutzerkontos . . . . 212
16.14 Sequenzdiagramm: Abrufen der Suchgeschichte . . . . . . . . . . . . . . . 212
16.15 Sequenzdiagramm: Abrufen der Dokumentenübersicht . . . . . . . . . . . 213
16.16 Sequenzdiagramm: Ändern des Accounts der digitalen Bibliothek . . . . . 214
16.17 Sequenzdiagramm: Ändern der Sucheinstellungen . . . . . . . . . . . . . 214
16.18 Sequenzdiagramm: Ändern der Benachrichtigungseinstellungen . . . . . . 215
16.19 Sequenzdiagramm: Speichern der Suchgeschichte . . . . . . . . . . . . . . 215
16.20 Sequenzdiagramm: Verlängerung der Dokumente . . . . . . . . . . . . . . 216
16.21 Sequenzdiagramm: Vormerken der Dokumente . . . . . . . . . . . . . . . 217
296

Abbildungsverzeichnis
16.22 Sequenzdiagramm: Löschen der vorgemerkten Dokumente . . . . . . . . . 217
16.23 GUI: Gesamtansicht im Liferay-Portal . . . . . . . . . . . . . . . . . . . . 218
16.24 GUI: Liferay Navigations-Portlet . . . . . . . . . . . . . . . . . . . . . . . 219
16.25 GUI: Such-Portlet (Einfache Suche) . . . . . . . . . . . . . . . . . . . . . 219
16.26 GUI: Such-Portlet (Erweiterte Suche) . . . . . . . . . . . . . . . . . . . . 220
16.27 GUI: Such-Portlet (Ergebnisausgabe) . . . . . . . . . . . . . . . . . . . . 221
16.28 GUI: Such-Portlet (Ergebnisausgabe mit Volldarstellung) . . . . . . . . . 222
16.29 GUI: Benutzerkonto-Portlet (Persönliche Daten) . . . . . . . . . . . . . . 223
16.30 GUI: Benutzerkonto-Portlet (Suchkriterien Einstellungen) . . . . . . . . . 223
16.31 GUI: Benutzerkonti-Portlet (Dokumentenübersicht) . . . . . . . . . . . . 224
16.32 GUI: Benutzerkonto-Portlet (Weitere Einstellungen) . . . . . . . . . . . . 225
16.33 GUI: Beispiel für ein Informations-Portlet (Önungszeiten) . . . . . . . . 225
16.34 GUI: Lesezeichen-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
16.35 GUI: Portlet-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
17.1 Gesamtpaketübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
17.2 Paket org.pgportal.ejb.dto (globale Informationen) . . . . . . . . . . 236
17.3 Paket org.pgportal.ejb.dto.request (Anfrage-Objekte) . . . . . . . . 237
17.4 Paket org.pgportal.ejb.dto.result (Ergebnis-Objekte) . . . . . . . . 239
17.5 Paket org.pgportal.ejb.dto.definitions (Objekte für allgemeine De-
nitionen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
17.6 Paket org.pgportal.ejb.util (Hilfsklassen) . . . . . . . . . . . . . . . 241
17.7 Klassendiagramm der Suchlogik . . . . . . . . . . . . . . . . . . . . . . . 245
17.8 Klassendiagramm des Mediators . . . . . . . . . . . . . . . . . . . . . . . 247
17.9 Paket org.pgportal.ejb.wrapper (DefaultWrapper) . . . . . . . . . . . 248
17.10 Paket org.pgportal.ejb.wrapper.sru (Wrapper zur Suche auf SRUbasierenden
Quellen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
17.11 Klassendiagramm des OAI-Wrappers . . . . . . . . . . . . . . . . . . . . 250
17.12 Klassendiagramm des OAI-Harvester . . . . . . . . . . . . . . . . . . . . 251
17.13 Paket org.pgportal.ejb.wrapper.OAI (OAI-Objekte) . . . . . . . . . . 252
17.14 Klassendiagramm des Benutzerkontos . . . . . . . . . . . . . . . . . . . . 253
17.15 Paket org.pgportal.ejb.userAccount (Benutzerkonto-Objekte) . . . . 254
17.16 GUI: Portlet-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
17.17 Pakete org.pgportal.portlet und org.pgportal.portlet.util . . . . 256
17.18 GUI: Vergleich der Gesamtansicht, siehe Abb. 16.23 . . . . . . . . . . . . 256
17.19 GUI: Vergleich der Einfachen Suche . . . . . . . . . . . . . . . . . . . . . 257
17.20 GUI: Vergleich der Ergebnis-Anzeige, siehe Abbildung 16.27 . . . . . . . 257
17.21 GUI: Vergleich der Detailansicht eines Ergebnisses, siehe Abbildung 16.28 258
17.22 GUI: Vergleich der Einstellungen . . . . . . . . . . . . . . . . . . . . . . 259
17.23 GUI: Vergleich der Dokumentenübersicht, siehe Abbildung 15.10 . . . . . 260
17.24 GUI: Portlet Suchchronik . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
17.25 GUI: Ausschnitt aus der Hilfe . . . . . . . . . . . . . . . . . . . . . . . . 261
18.1 Einfache Suche, Eingabefeld der Suche . . . . . . . . . . . . . . . . . . . 264
18.2 Einfache Suche, Denition des Suchraums . . . . . . . . . . . . . . . . . . 265
18.3 Erweiterte Suche, verschiedene Kategorien: Titel, Autor und Schlagwort . 265
18.4 Erweiterte Suche, Deniton des Suchraums . . . . . . . . . . . . . . . . . 266
18.5 Erweiterte Suche, ndbare Medientypen . . . . . . . . . . . . . . . . . . . 266
18.6 Such-Chronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
297

Abbildungsverzeichnis
18.7 Ergebnisanzeige, Statistiken . . . . . . . . . . . . . . . . . . . . . . . . . 267
18.8 Ergebnisanzeige, aufgeklapptes Ergebnis . . . . . . . . . . . . . . . . . . 268
18.9 Benutzerkonto, Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 268
18.10 Benutzerkonto, Mahngebühren . . . . . . . . . . . . . . . . . . . . . . . . 269
18.11 Benutzerkonto, selbst ausgeliehene Dokumente . . . . . . . . . . . . . . . 269
18.12 Benutzerkonto, eigene Vormerkungen . . . . . . . . . . . . . . . . . . . . 270
18.13 Benutzerkonto, persönliche Daten . . . . . . . . . . . . . . . . . . . . . . 270
18.14 Navigation, Ausgangszustand . . . . . . . . . . . . . . . . . . . . . . . . 271
18.15 Navigation, Zustand nach Wahl einer Hauptseite . . . . . . . . . . . . . . 271
18.16 Reiter innerhalb der Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . 271
B.1 Die Helden des Tages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
298

Tabellenverzeichnis
7.1 Im Portlet-API denierte Fensterzustände . . . . . . . . . . . . . . . . . 73
16.1 Klasse SearchBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
16.2 Klasse UricaSRURessource . . . . . . . . . . . . . . . . . . . . . . . . . . 207
16.3 Klasse SRUWrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
16.4 Klasse SRUParser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
16.5 Klasse CiteSeerRessource . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.6 Klasse CiteSeerWrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.7 Klasse HibernateUtil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
16.8 Klasse UserAccountBean . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
16.9 Allgemeine JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16.10 Such-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16.11 Benutzerkonto-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16.12 Lesezeichen-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16.13 Hilfe-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
16.14 Önungszeiten-Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
16.15 Entität UserAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
16.16 Entität SearchHistory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
299

Listings
7.1 Deployment-Deskriptor mit Portlet-Preferences . . . . . . . . . . . . . . . 74
7.2 Deployment-Deskriptor mit User-Attributes . . . . . . . . . . . . . . . . . 75
7.3 Deployment-Deskriptor portlet.xml . . . . . . . . . . . . . . . . . . . . . . 76
7.4 Deployment-Deskriptor web.xml . . . . . . . . . . . . . . . . . . . . . . . . 77
9.1 Beispiel: Original MARC (Ausschnitt) . . . . . . . . . . . . . . . . . . . . 96
9.2 Beispiel: MARCXML Instance (Ausschnitt) . . . . . . . . . . . . . . . . . 96
9.3 Beispiel: Dublin Core Transformation (Gesamtes Dokument) . . . . . . . . 96
13.1 Beispiel: Publikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.2 Beispiel: MARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.3 Beispiel: MARCXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.4 Beispiel: MODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.5 Beispiel: EAD-Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
13.6 Beispiel: OAI Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.7 Beispiel: OAI Antwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.8 Beispiel: METS Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
300

Literaturverzeichnis
[AH03] Abdelnur, A. ; Heppner, S.: Java Portlet Specication Version
1.0. Version: 2003. http://jcp.org/aboutJava/communityprocess/final/
jsr168/index.html, Abruf: 08.04.2006
[Arm99] Arms, William (Hrsg.): Digital Libraries. Version: 1999. URL:http:
//www.cs.cornell.edu/wya/DigLib/MS1999/Chapter10.html, Abruf:
14. April. 2006
[Arm00] Arms, William Y.: Digital Libraries. M.I.T. Press, 2000
[BL96]
[BO]
Berners-Lee, Tim: WWW: Past, Present, and Future. In: IEEE Computer
29 (1996), Nr. 10, S. 6977
BR-Online (Hrsg.): Geheimnisse des Projektmanagements. http://www.
br-online.de/wissen-bildung/thema/projektmanagement/index.xml ,
Abruf: 04.06.2005
[Bra99] Braunschweig, UB (Hrsg.): Was sind und was sollen Bibliothekarische
Datenformate. Version: 1999. URL:http://www.allegro-c.de/formate/
formate.htm, Abruf: 14. April. 2006
[Che76]
[DH03]
Chen, Peter P.: The Entity-Relationship Model - Toward a Unied View of
Data. In: ACM Transactions on Database Systems 1 (1976), Nr. 1, S. 936
Dunkel, Jürgen ; Holitschke, Andreas: Softwarearchitektur für die Praxis.
Springer, Berlin, 2003. ISBN 3540002219
[diea] dieDeutscheBibliothek (Hrsg.): MAB. URL:http://www.ddb.de/
standardisierung/formate/mab.htm, Abruf: 14. April. 2006
[dieb] dieDeutscheBibliothek (Hrsg.): MABxml. URL:http://www.ddb.de/
standardisierung/formate/mabxml.htm, Abruf: 14. April. 2006
[DLWZ03] Dumke, Reiner ; Lother, Mathias ; Wille, Cornelius ; Zbrog, Fritz: Web
Engineering. Pearson Studium, 2003
[Fri96]
Friedrich, Marc: Entwurf und Implementierung von Verfahren zur Bestimmung
von Textinhalten aus Verkehrsmeldungen für die Überführung in das
digitale RDS-TMC-Format, Technische Hochschule Darmstadt, Diplomarbeit,
1996. http://www.smile-datentechnik.de/projekte/dipl/index.html
301

Literaturverzeichnis
[GGSB98] Gill, T. ; Gilliland-Sweetland, A. ; Baca, M.: Introduction to Metadata
- Pathways to Digital Information. Getty Information Institute, 1998
[GM01]
[Has00]
Ginige, Athula ; Murugesan, San: Guest Editors' Introduction: The Essence
of Web Engineering - Managing the Diversity and Complexity of Web
Application Development. In: IEEE MultiMedia 8 (2001), Nr. 2, S. 2225
Hasselbring, Wilhelm: Information system integration. In: Communications
of the ACM 43 (2000), Juni, Nr. 6, 3238. http://www.acm.org/pubs/
citations/journals/cacm/2000-43-6/p32-hasselbring/. ISSN 0001
0782
[Ini] Initiative, Dublin Core M. (Hrsg.): Dublin Core Metadata Element Set.
URL:http://www.dublincore.org/documents/dces/, Abruf: 14. April. 2006
[Ker04a] Kerpen, C.: Mach auf das Tor! In: JavaMagazin 10/04 (2004)
[Ker04b]
[Knu73]
Kerpen, Claus: JSR 168, die Portlet-Spezikation. Software Support Verlag
GmbH, 2004
Knuth, Donald E.: The Art of Computer Programming. Addison-Wesley,
1973
[KPRR04] Kappel, Gerti ; Pröll, Birgit ; Reich, Siegfried ; Retschnitzegger, Werner:
Web Engineering: Systematische Entwicklung von Web-Anwendungen.
dpunkt.verlag, 2004
[Lev66]
Levenshtein, V.I.: Binary codes capable of correcting deletions, insertions
and reversals. In: Sov. Phys. Dokl. 6 (1966), S. 707710
[LM04a] Linwood, J. ; Minter, D.: Building Portals with the Java Portlet API.
Apress, 2004
[LM04b]
[LOCa]
[LOCb]
[Mar02]
[MEH01]
Linwood, Je ; Minter, Dave: Building Portals with the Java Portlet API.
Springer Verlag, 2004
LOC (Hrsg.): MARC 21 - MAchine Readable Catalog. http://www.loc.gov/
marc/faq.html#definition, Abruf: 16.04.2006
LOC (Hrsg.): METS - Metadata Encoding and Transmission Standard. http:
//www.loc.gov/standards/mets/, Abruf: 16.04.2006
Marinescu, Floyd: EJB Design Patterns: Advanced Patterns, Processes, and
Idioms. Wiley, 2002
Maier, Mark W. ; Emery, David E. ; Hilliard, Rich: Software Architecture:
Introducing IEEE Standard 1471. In: IEEE Computer 34 (2001), Nr. 4, 107
109. http://dlib.computer.org/co/books/co2001/pdf/r4107.pdf
[Mic03] Microsystems, Sun (Hrsg.): Introduction to JSR 168 - The Portlet
Specication. Version: 2003. http://developers.sun.com/prodtech/
portalserver/reference/techart/jsr168/pb_whitepaper.pdf, Abruf:
04.04.2006
302

Literaturverzeichnis
[MS97]
[Pay]
Mitchell, W.I. ; Strimpel, O.: There and not there. In Denning and Metcalfe.
(1997)
Payer, Margarete: Digitale Bibliothek: Biblioteca digital. http://www.payer.
de/einzel/digitalebolivien.htm, Abruf: 12.04.2006
[Ric04] Richardson, W.C.: Portal Development with Open Source Tools. Wrox
Press, 2004
[RS77]
Reth, Hans-Peter von ; Schek, Hans-Jörg: Eine Zugrismethode für die
phonetische Ähnlichkeitssuche / Wissenschaftliches Zentrum Heidelberg. 1977.
Forschungsbericht
[Sel] Selfhtml (Hrsg.): Web-Projektverwaltung. http://de.selfhtml.org/
projekt/planen.htm, Abruf: 04.01.2005
[Som01] Sommerville, Ian: Software Engineering. 6th. Pearson Studium, 2001
[SSNM97] Schmidt, Joachim W. ; Schröder, Gerald ; Niederée, Claudia ; Matthes,
Florian: Linguistic and Architectural Requirements for Personalized Digital
Libraries. In: Int. J. on Digital Libraries 1 (1997), S. 89104
[Sto04]
Stoyan, R.: Management von Webprojekten - Führung, Projektplan, Vertrag.
Springer Verlag, 2004
[Sun04] Sun Microsystems, Inc.: J2EE, Enterprise JavaBeans Technology. (2004).
http://java.sun.com/products/ejb/, Abruf: 16. April 2006
[Sun05]
[SW02]
[TO]
Sun Microsystems, Inc.: Java 2 Platform, Enterprise Edition (J2EE) Overview.
(2005). http://java.sun.com/j2ee/appmodel.html, Abruf: 16. April
2006
Sneed, Harry M. ; Winter, Mario: Testen objektorientierter Software. Hanser,
2002
T-Online (Hrsg.): Web-Projektplanung. http://www3.t-online-business.
de/dyn/c/12/88/60/1288600.html, Abruf: 04.06.2005
[vir] virtualuniversity (Hrsg.): Management. http://www.
virtualuniversity.ch/management/index.html, Abruf: 04.01.2005
[W3C]
W3C (Hrsg.): World Wide Web Consortium (W3C). http://www.w3.org,
Abruf: 06.04.2006
[WCa] Wikipedia-Community (Hrsg.): Denition: Digital Subscriber Line
(DSL). http://de.wikipedia.org/wiki/Digital_Subscriber_Line, Abruf:
15.04.2006
[WCb] Wikipedia-Community (Hrsg.): Denition: Rangordnung. http://de.
wikipedia.org/wiki/Rangordnung, Abruf: 23.01.2006
[WCc] Wikipedia-Community (Hrsg.): Denition: Suchfunktion. http://de.
wikipedia.org/wiki/Suchfunktion, Abruf: 23.01.2006
303

Literaturverzeichnis
[WCd]
[WCR04]
Wikipedia-Community (Hrsg.): Denition: World Wide Web. http://de.
wikipedia.org/wiki/World_Wide_Web, Abruf: 13.04.2006
W. Clay Richardson, Joe Vitale Peter Len und Kevin T. S. Donald Avondolio
A. Donald Avondolio: Professional Portal Development with Open Source
Tools: Java Portlet API, Lucene, James, Slide. Wiley Technology Publishing,
2004
304