Hierarchische Benutzerverwaltung unter Hyperwave

Hierarchische Benutzerverwaltung unter Hyperwave
System zur hierarchischen Benutzerverwaltung
und Subadministration
Diplomarbeit
an der
Technischen Universität Graz
vorgelegt von
Harald Schwarzmann
Institut für Informationsverarbeitung und Computergestützte neue Medien IICM
Technische Universität Graz
A-8010 Graz
Österreich
Oktober 1999
© Copyright 1999, Harald Schwarzmann
Begutachter:
Betreuer:
o.Univ.-Prof. Dr. Dr.h.c. Hermann Maurer
Dipl.-Ing. Christian Gütl
Kurzfassung
Die für das weltweit öffentlich zugängliche World Wide Web genutzten Technologien
werden zunehmend auch für firmeninterne Netzwerklösungen herangezogen.
Innerbetriebliche Informationen werden in sogenannten Intranets organisiert und können
von Mitarbeitern über gewöhnliche Internet-Clients (Browser) abgerufen werden. Um den
Zugriff auf diese Informationen zu regeln, müssen sich Mitarbeiter am System durch Login
und Paßwort identifizieren. Durch eine erfolgreiche Identifikation kann dem Benutzer
erlaubt werden Daten am Server zu modifizieren und zu löschen. Außerdem können auf
diese Weise Daten vor unerlaubten Zugriffen durch nicht berechtigte Benutzer geschützt
werden. Die zur Identifikation notwendigen Benutzerdaten werden von den
Systemadministratoren des Servers verwaltet. Werden in einem System sehr viele Benutzer
administriert, so entsteht durch die Verwaltung der Benutzerdaten eine zusätzliche
Belastung der Systemadministratoren. Die Aufgabe der Benutzeradministration soll daher
aus dem Aufgabenbereich der Systemadministratoren ausgelagert werden.
Die in der vorliegenden Arbeit entwickelte hierarchische Benutzerverwaltung ermöglicht
besonders ausgezeichneten Benutzern ohne Systemrechte, neue Benutzer in bestimmten,
hierarchisch angeordneten Bereichen zu erzeugen. Durch die Loslösung der
Benutzerverwaltung aus dem Aufgabenbereich der Systemadministratoren werden diese
entlastet.
Im Untersuchungsbereich dieser Arbeit wird analysiert, wie ein System zur hierarchischen
Benutzerverwaltung realisiert werden kann. Dabei sollen möglichst viele Varianten
untersucht werden, welche die Umsetzung eines Systems zur hierarchischen
Benutzerverwaltung unter Hyperwave ermöglichen. Es sollen bereits verfügbare Lösungen
und Systeme in Hinblick auf eine hierarchische Benutzerverwaltung untersucht werden, als
auch eigene Lösungsansätze entwickelt werden. Danach sollen die Vor- und Nachteile
dieser Varianten diskutiert werden, bevor am Ende des Untersuchungsbereiches ein
konkretes Konzept zur Umsetzung einer hierarchischen Benutzerverwaltung unter
Hyperwave abgeleitet wird.
Im Gestaltungsbereich wird die im Untersuchungsbereich ausgewählte Variante zur
Umsetzung einer hierarchischen Benutzerverwaltung unter Hyperwave implementiert. Die
Entwicklung der hierarchischen Benutzerverwaltung wird nach den Methoden des
Projektmanagements vorgenommen, um eine erfolgreiche Durchführung des Projektes
„hierarchische Benutzerverwaltung unter Hyperwave“ erreichen zu können.
Diese Arbeit wurde in Zusammenarbeit mit einem großen deutschen Elektronik-Konzern
durchgeführt.
Abstract
The technologies, which keep the World Wide Web running, are increasingly used for
internal network-solutions. Informations are organized in so-called „Intranets“ and can be
accessed via conventional internet-clients (browsers). To control the access to this
informations, users have to identify on the system. A successful identification allows users
to modify and delete documents on the server. Further, the documents, which are stored on
the server, can be protected from unauthorized access in this way. The information, which
is needed for user-identification is maintained by the system-administrators of the server. If
the number of administrated users is very large, the task of user-administration burdens
additional load on the system-administrators. Therefore user-administration should be
shiftet from system-administrators to another group of users.
In this thesis a system for hierarchical usermanagement is developed. This system allows a
privileged group of users without system-privileges to create new users in appointed and
hierarchical ordered domains. This arrangement makes it possible to release the systemadministrators from the tasks of usermanagement.
In the theoretical part of this thesis several possibilities for implementing a hierarchical
usermanagement are researched. Many concepts, which can be used for integrating such a
system in hyperwave, should be analyzed. Not only already existing system should be
examined towards a hierarchical usermanagement, but also new concepts should be
developed. The advantages and disandvantages of this concepts should be discussed,
before a concrete concept for developing a hierarchical usermanagement is choosen at the
end of the theoretical part of this thesis.
The selected concept is implemented in the practical part and integrated into the
functionality of a Hyperwave Information Server Version 4.1. The development and design
of the component for hierarchical usermanagement uses the methods of software
engineering, to reach a successful completition of the project.
The component for hierarchical usermanagement was developed in collaboration with a
large german electronic-concern.
Danksagung
An dieser Stelle möchte ich mich bei all jenen bedanken, die mir beim Erstellen dieser
Arbeit durch ihre Unterstützung zur Seite standen.
Allen voran o.Univ.-Prof. Dr. Dr.h.c. Hermann Maurer, Leiter des Instituts für
Informationsverarbeitung und computergestützte neue Medien (IICM) und Begutachter
dieser Arbeit, sowie meinem Betreuer Dipl.-Ing. Christian Gütl, der mir durch seine
intensive Betreuung und vor allem durch oftmaliges Korrekturlesen sehr geholfen hat.
Weiters möchte ich mich an dieser Stelle bei den Institutsangestellten des IICMs für ihre
technische Unterstützung, sowie bei meiner Partnerin Katharina für ihre Ausdauer und
Geduld bedanken.
Ganz besonders bedanken möchte ich mich bei meinen Eltern Hedwig und Manfred, die
mein Studium erst ermöglicht haben, mich all die Jahre hinweg tatkräftig unterstützt haben
und meinen Plänen und Wünschen gegenüber immer offen waren.
Ich versichere hiermit, diese Arbeit selbständig verfaßt, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel
bedient zu haben.
Inhaltsverzeichnis
Kapitel 1 Einleitung ............................................................................................................. 1
1.1
1.2
1.3
Ausgangssituation und Motivation ..................................................................................... 1
Formale Vereinbarungen und notwendige Definitionen..................................................... 3
Schlußbemerkung ............................................................................................................... 3
Kapitel 2 Projektplanung .................................................................................................... 5
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.5.3
2.6
Einleitung............................................................................................................................ 5
Der Software-Entwicklungsprozeß ..................................................................................... 6
Das Software-Prozeßmodell ............................................................................................... 7
Projektmanagement .......................................................................................................... 10
Aufwandsabschätzung .................................................................................................11
Der Projektplan............................................................................................................12
Meilensteine ................................................................................................................12
Projektplanung am Beispiel der hierachischen Benutzerverwaltung ................................ 12
Aufwandsabschätzung .................................................................................................13
Meilensteine ................................................................................................................16
Projektplan...................................................................................................................16
Schlußbemerkung ............................................................................................................. 18
Kapitel 3 Requirements Specification .............................................................................. 21
3.1
3.2
3.3
3.4
3.4.1
3.4.2
3.5
Einleitung.......................................................................................................................... 21
Analyse des Umfelds ........................................................................................................ 22
Problemanalyse ................................................................................................................. 23
Systemanforderungen ....................................................................................................... 23
Funktionale Systemanforderungen ..............................................................................24
Nichtfunktionale Systemanforderungen ......................................................................29
Schlußbemerkung ............................................................................................................. 30
Kapitel 4 Hyperwave – ein Überblick .............................................................................. 31
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.8.1
4.8.2
4.9
4.10
Was verbirgt sich hinter dem Namen „Hyperwave“? ....................................................... 31
Objekte in Hyperwave ...................................................................................................... 32
Benutzerverwaltung .......................................................................................................... 35
Rechtevergabe................................................................................................................... 37
Architektur des Hyperwave-Servers ................................................................................. 39
Der Wavemaster ............................................................................................................... 40
PLACE .............................................................................................................................. 42
JavaScript in Hyperwave .................................................................................................. 44
HWJS...........................................................................................................................45
JavaScript in den Wavemaster-Templates...................................................................47
Hyperwave & CGI ............................................................................................................ 50
Schlußbemerkung ............................................................................................................. 52
Inhaltsverzeichnis
ii
Kapitel 5 Lösungssuche ..................................................................................................... 53
5.1
Variantenbildung .............................................................................................................. 54
5.1.1
Derzeitige Konzepte ....................................................................................................54
5.1.2
Entwicklung eigener Konzepte....................................................................................59
5.1.3
Sicherheit .....................................................................................................................63
5.1.4
Hohe Benutzeranzahl...................................................................................................64
5.1.5
Benutzerfreundlichkeit ................................................................................................64
5.1.6
Zusammenfassung .......................................................................................................65
5.2
Synthese ............................................................................................................................ 65
5.3
Schlußbemerkung ............................................................................................................. 67
Kapitel 6 Technischer Entwurf der ausgewählten Variante .......................................... 69
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.8.1
6.8.2
6.8.3
6.8.4
6.9
6.9.1
6.9.2
6.9.3
6.9.4
6.10
6.11
6.12
6.13
6.14
Einleitung.......................................................................................................................... 69
Einbindung der hierarchischen Benutzerverwaltung in Hyperwave................................. 70
Dialoge & Funktionen der hierarchischen Benutzerverwaltung ....................................... 71
Gestaltung der Dialoge zur hierarchischen Benutzerverwaltung ...................................... 79
Behandlung der Requests der hierarchische Benutzerverwaltung .................................... 83
Objektorientiertes Programmieren in JavaScript .............................................................. 84
Die JavaScript-Bibliothek hwlib ....................................................................................... 88
Objektorientierte Entwurfsmethodik ................................................................................ 91
Identifizieren der Klassen und Objekte .......................................................................91
Identifizieren der Verantwortlichkeiten.......................................................................92
Identifizieren der Beziehungen ....................................................................................92
Implementierung der Klassen und Objekte .................................................................93
Objektorientierter Entwurf................................................................................................ 93
Identifizieren der Klassen und Objekte .......................................................................93
Identifizieren der Verantwortlichkeiten.......................................................................94
Identifizieren der Beziehungen ....................................................................................99
Implementierung der Objekte ....................................................................................100
Entwurf der SSJS-Scripts................................................................................................ 113
Dateistruktur der Daten zur hierarchischen Benutzerverwaltung ................................... 114
Beispiel eines Script-Entwurfes ...................................................................................... 115
Planung der Implementierungsphase .............................................................................. 116
Schlußbemerkung ........................................................................................................... 117
Kapitel 7 Die Implementierungsphase ........................................................................... 119
7.1
7.2
7.3
7.4
7.5
Einleitung........................................................................................................................ 119
Umgebung und Tools ..................................................................................................... 119
Richtlinien....................................................................................................................... 122
Implementierung ............................................................................................................. 125
Schlußbemerkung ........................................................................................................... 126
Kapitel 8 Testphase .......................................................................................................... 127
8.1
Einleitung........................................................................................................................ 127
8.2
Ablauf der Testphase ...................................................................................................... 128
8.2.1
Unit Testing ...............................................................................................................128
8.2.2
Integration Testing.....................................................................................................129
8.2.3
System Testing ..........................................................................................................131
8.3
Testphase des Systems zur hierarchischen Benutzerverwaltung unter Hyperwave........ 132
8.3.1
Unit Testing ...............................................................................................................133
Inhaltsverzeichnis
iii
8.3.2
Integration Testing.....................................................................................................134
8.3.3
System Testing ..........................................................................................................135
8.4
Schlußbemerkung ........................................................................................................... 136
Kapitel 9 Integration ........................................................................................................ 137
9.1
9.2
9.3
9.4
9.5
Einleitung........................................................................................................................ 137
Schulungen ..................................................................................................................... 137
Dokumentation ............................................................................................................... 138
Integration des Systems zur hierarchischen Benutzerverwaltung................................... 139
Schlußbemerkung ........................................................................................................... 139
Kapitel 10 Ausblick ........................................................................................................ 140
Kapitel 11 Zusammenfassung ....................................................................................... 141
Kapitel 1 Einleitung
1.1 Ausgangssituation und Motivation
Die Bedeutung von Intranetlösungen für große und mittelständische Unternehmen hat sich
in den letzten Jahren deutlich vergrößert. Durch zunehmend einfachere Anwendungen und
leicht zu bedienende Netzdienste wird der Zugang und die Nutzung dieses Mediums immer
beliebter. Die sich daraus ergebenden Möglichkeiten, firmeninterne Informationen über
eine Intranet-Anwendung anzubieten und abzurufen, werden immer umfangreicher und
deshalb immer häufiger genutzt.[ITC98] Der Hyperwave Information Server 1 bietet eine
komfortable und leistungsfähige Möglichkeit, ein solches Service anzubieten. Neben
integriertem Link-Management und Meta-Information unterstützt Hyperwave auch eine
"Multiple-Authoring" Umgebung. Durch das Festlegen von Zugriffsrechten können die
eigenen Dateien vor Zugriffen anderer Benutzer geschützt werden. Unterschiedliche
Benutzer können unterschiedliche Zugriffsrechte erhalten und so z.B. als
Systemadministratoren, Autoren oder normale Benutzer, die nur lesend auf Dateien
zugreifen dürfen, am System arbeiten. Das Recht, neue Benutzer zu erzeugen ist aber, wie
in den meisten Systemen, die eine Benutzerverwaltung unterstützen, den
Systemadministratoren vorenthalten (siehe auch Kapitel 5.1.1). Das ist unter gewissen
Umständen eine unnötige Einschränkung. Es kann auch Benutzern ohne Systemrechten
erlaubt werden, neue Benutzer am System zu erzeugen, wenn bestimmte Vorkehrungen
getroffen werden, um zu verhindern, daß diese Benutzer ihre Kompetenzen überschreiten
und Schaden am System anrichten. In dieser Arbeit wird eine hierarchische
Benutzerverwaltung (siehe Kapitel 3.4) ausgearbeitet, die diese Vorgehensweise
ermöglicht. Die hierarchische Benutzerverwaltung erlaubt auch Benutzern ohne
Systemrechten in bestimmten Bereichen weitere Benutzer zu erzeugen.
Ziel der vorliegenden Arbeit ist, im ersten Schritt, dem Untersuchungsbereich, ein Konzept
zu erstellen, wie ein System zur hierarchischen Benutzerverwaltung in die Funktionalität
des Hyperwave Information Servers eingebunden werden kann. Dazu sollen auch bereits
existierende Lösungen und Systeme analysiert werden, um eine optimale Lösung finden zu
können. Im zweiten Schritt, dem Gestaltungsbereich, soll dieses Konzept in die Praxis
umgesetzt und zur Produktreife gebracht werden.
1
http://www.hyperwave.com
Kapitel 1: Einleitung
2
Die Durchführung dieser Arbeit erfolgt nach den Methoden des Projektmanagements
(siehe Kapitel 2). Dieser Ansatz wurde gewählt, da die Entwicklung von
Softwarekomponenten ein sehr komplexer Vorgang ist. Laut Pfleeger [Pfl98] sind die drei
wesentlichen Ziele eines jeden Projekts:

Sicherstellung von qualitativer Hochwertigkeit des fertiggestellten Produkts

Effiziente Planung und Umsetzung des Projekts

Garantie einer langen Lebensdauer des fertiggestellten Produkts.
Um diese Ziele erreichen zu können, muß an die Aufgaben bei der Entwicklung von
Software methodisch herangegangen werden. Außerdem soll anhand der vorliegenden
Arbeit untersucht werden, ob sich die Methoden des Projektmanagements auch zur
Durchführung von Kleinstprojekten mit einer Projektgruppe von 1-3 Personen und einem
Aufwand kleiner 6 Mannmonaten eignen.
Die Durchführung dieser Arbeit gliedert sich in zwei Bereiche. Im Untersuchungsbereich
wird ein geeignetes Konzept erstellt, wie eine hierarchische Benutzerverwaltung in die
Funktionalität des Hyperwave Information Servers eingebunden werden kann. Die
Vorgehensweise erfolgt nach den Methoden der Projektplanung nach Pfleeger [Pfl98] und
orientiert sich am Wasserfall-Modell (siehe auch Kapitel 2, Projektplanung):

In Kapitel 3 werden die Anforderungen2 an das System festgelegt. Diese
Anforderungen dienen als Ausgangspunkt und Grundlage für alle weiteren
Untersuchungen.

Da die hierarchische Benutzerverwaltung auf der Grundlage eines Hyperwave
Information Servers aufgebaut werden soll, werden in Kapitel 4 die Eigenschaften des
Hyperwave Information Servers in Bezug auf die zu lösende Problemstellung
untersucht.

In Kapitel 5, dem letzten Abschnitt des Untersuchungsbereiches, wird schließlich eine
konkrete Möglichkeit erarbeitet, um eine hierarchische Benutzerverwaltung zu
realisieren. Dazu sollen auch bereits existierende Systeme im Hinblick auf eine
hierarchische Benutzerverwaltung analysiert werden, um eine optimale Lösung finden
zu können.
Im zweiten Bereich der Arbeit, dem Gestaltungsbereich, wird die im Untersuchungsbereich
gefundene Variante der hierarchischen Benutzerverwaltung implementiert:

In Kapitel 6 wird die Implementierung der hierarchischen Benutzerverwaltung im
Detail geplant. Das Design der hierarchischen Benutzerverwaltung folgt den Methoden
des OOD3 und orientiert sich dabei speziell an der Methode von Booch[Boo92].

Kapitel 7 beschreibt die Implementierungsphase der hierarchischen Benutzerverwaltung. Die dabei aufgetretenen Probleme, deren Lösungen und die verwendeten
Tools werden beschrieben.
2
Requirements Specification
3
Objektorientiertes Design
Kapitel 1: Einleitung
3

In Kapitel 8 werden die verwendeten Testmethoden beschrieben. Die Testphase
gliedert sich in die Bereiche Unit Testing und System Testing.

Kapitel 9 beschreibt, welche Schritte nach Abschluß der Testphase vorgenommen
werden müssen, um das System zur hierarchischen Benutzerverwaltung beim
Auftraggeber einzubinden.

Am Ende dieser Arbeit sollen in Kapitel 10 schließlich Perspektiven zur
Weiterentwicklung der in dieser Arbeit implementierten hierarchischen
Benutzerverwaltung aufgezeigt werden.
Es soll an dieser Stele noch angemerkt werden, daß diese Arbeit in Zusammenarbeit mit
der Wirtschaft durchgeführt wurde. Die hierarchische Benutzerverwaltung wurde für einen
großen deutschen Elektronik-Konzern entwickelt.
1.2 Formale Vereinbarungen und notwendige
Definitionen
Um Befehle, Rechneradressen, Dateinamen usw. besser vom übrigen Text abzuheben,
werden sie typographisch vom übrigen Text hervorgehoben. Dafür werden die in Tabelle
1.1 aufgezeigten formalen Vereinbarungen getroffen.
Auszeichnung
Bedeutung
kursiv
Begriffsdefinitionen werden kursiv dargestellt.
Nichtproportionalschrift
http://www.hyperwave.de
Programmausdrucke, Dateiinhalte, und Muster von
Bildschirmtext
werden
in
Nichtproportionalschrift
dargestellt.
Internet-Adressen
werden
ebenfalls
unterstrichenen Schrifttyp dargestellt.
in
einem
Tabelle 1.1: Typografische Vereinbarungen
1.3 Schlußbemerkung
Nachdem in diesem Kapitel nur ein kurzer Überblick über die vorliegende Arbeit und
deren Motivation gegeben wurde, soll im nächsten Kapitel auf die Planung des
vorliegenden Projekts eingegangen werden. Wie bereits 1994 von der Standish-Group4,
eine Marktforschungs- und Beratungsfirma, gezeigt wurde, ist die Projektplanung ein
Faktor, der über den Erfolg oder Mißerfolg eines Projekts entscheiden kann. Dabei wurden
4
http://www.standishgroup.com
Kapitel 1: Einleitung
4
in über 350 Konzernen mehr als 8000 Softwareprojekte untersucht. Es wurde festgestellt,
daß 31% der Softwareprojekte bereits vor ihrer Fertigstellung abgebrochen wurden. In
großen Konzernen wurden nur 9% aller Projekte zum vereinbarten Termin und den
vorgegebenen Kosten geliefert. In kleinen Firmen konnten immerhin 16% der Projekte
diese Anforderung erfüllen. Um die Ursachen für dieses Dilemma festzustellen, wurden
die Befragten gebeten, die Gründe für das Scheitern ihrer Projekte anzugeben. Tabelle 1.2
zeigt die acht am häufigsten angegeben Gründe.[STA94]
Ursache
Prozent an gescheiterten Projekten
Unvollständige Systemanforderungen
13.1%
Zu wenig Absprache mit den Anwendern
12.4%
Zu wenig Ressourcen
10.6%
Unrealistische Erwartungen
9.9%
Zu geringe Unterstützung
9.3%
Änderung der Systemanforderungen
8.7%
Zu wenig Planung
8.1%
System wurde nicht mehr gebraucht
7.5%
Tabelle 1.2: Ursachen für gescheiterte Projekte
Anhand der aufgelisteten Ursachen kann man erkennen, daß bei allen angeführten
Problemen die Planung des Projekts eine bestimmte Rolle spielt. Daher ist eine
methodische und gewissenhafte Planungsphase am Beginn eines Projekts ein
unverzichtbarer Schritt, um eine erfolgreiche Projektdurchführung gewährleisten zu
können. Im nächsten Kapitel soll daher, bevor im Untersuchungsbereich mit der Suche
nach Möglichkeiten zur Umsetzung einer hierarchischen Benutzerverwaltung begonnen
wird, auf die Planung des Projekts eingegangen werden. Aufgabe der Projektplanung ist
das schriftliche Festhalten und zeitliche Ordnen der Tätigkeiten, die durchgeführt werden
müssen, um das Projekt erfolgreich abschließen zu können. [Pfl98]
Kapitel 2
Projektplanung
2.1 Einleitung
Wie Tabelle 1.2 in Kapitel 1.3 zeigt, ist die Projektplanung ein Kriterium, das über den
Erfolg oder Mißerfolg eines Projekts entscheiden kann. Aufgabe der Projektplanung ist die
Tätigkeiten, die im Rahmen des Projekts durchgeführt werden müssen und deren
Abhängigkeiten untereinander zu analysieren und zu ordnen. Mitarbeiter können den
fertiggestellten Projektplan verwenden, um sich über die Tätigkeiten zu informieren, die
von ihnen im Rahmen des Projekts erledigt werden müssen. Anhand des Projektplans kann
auch der Projekfortschritt gemessen werden. Der Projektplan wird auch benutzt, um mit
dem Auftraggeber zeitliche und finanzielle Aspekte abzuklären. [Pfl98] Bevor in diesem
Kapitel auf die konkrete Planung des Projekts „Hierarchische Benutzerverwaltung unter
Hyperwave“ eingegangen wird, sollen die Aufgaben der Projektplanung untersucht
werden. Um die Aufgaben der Projektplanung genau analysieren zu können, soll zunächst
geklärt werden, wie der Prozeß der Software-Entwicklung in der Praxis abläuft. Am
Beginn dieses Kapitels wird daher die Bedeutung des Begriffs „SoftwareEntwicklungsprozeß“ untersucht. Dabei soll geklärt werden, was man unter einem Prozeß
versteht. Im nächsten Schritt werden verschieden Modelle untersucht, die den Ablauf des
Software-Entwicklungsprozesses zu beschreiben versuchen. In der Literatur kann eine
große Zahl solcher Software-Prozeßmodelle gefunden werden. Jedes dieser Modelle
versucht den Software-Entwicklung-Prozeß unter einem anderen Gesichtspunkt zu
beschreiben. Nachdem in Kapitel 2.3 die wichtigsten Software-Prozeßmodelle untersucht
wurden, kann in Kapitel 2.4 auf die Aufgaben der Projektplanung eingegangen werden.
Am Ende dieses Kapitels wird schließlich die konkrete Projektplanung des in dieser Arbeit
beschriebenen Projekts „Hierarchische Benutzerverwaltung unter Hyperwave“
vorgenommen.
Kapitel 2: Projektplanung
6
2.2 Der Software-Entwicklungsprozeß
Immer wenn ein bestimmtes Produkt erzeugt wird, z.B. die Entwicklung neuer Software,
so folgt man einer bestimmten Reihenfolge von Schritten, um bestimmte Aufgaben zu
erfüllen. Diese Schritte werden fast immer in derselben Reihenfolge durchgeführt. So
werden z.B. beim Bau eines Hauses die Elektroinstallationen üblicherweise vor dem
Ausmalen der Räume vorgenommen. Eine solche geordnete Reihenfolge von Schritten
wird als Prozeß bezeichnet. Ein Prozeß hat die folgenden Eigenschaften: [Pfl98]

Ein Prozeß beschreibt alle wichtigen Schritte, die unternommen werden müssen, um
diesen durchzuführen.

Ein Prozeß verwendet bestimmte Ressourcen, produziert daraus Zwischenprodukte und
ein Endprodukt.

Ein Prozeß kann aus Teilprozessen zusammengesetzt sein, die in gewissen
Beziehungen zueinander stehen. Ein Prozeß kann aus einer Hierarchie von
Teilprozessen bestehen, die jeder für sich ihr eigenes Prozeßmodell haben.

Jeder Schritt in einem Prozeß hat ein definiertes Beginn- und Ende-Kiterium, so daß
festgestellt werden kann, wann der entsprechende Schritt beginnt und endet.

Die Schritte eines Prozesses haben eine bestimmte Reihenfolge, so daß geklärt ist,
wann ein Schritt relativ zu anderen Schritten ausgeführt werden muß.

Jeder Prozeß besitzt ein bestimmtes Ziel, daß durch seine Durchführung erreicht
werden soll.

Die Aktivitäten, Ressourcen und Produkte eines Prozesses sind bestimmten
Beschränkungen unterworfen. Zum Beispiel beschränkt die Zeit, die zur Durchführung
eines Prozesses zur Verfügung steht, dessen Dauer.
Wird durch einen Prozeß ein bestimmtes Produkt erzeugt so bezeichnet man diesen Prozeß
auch oft als Life-Cycle. Der Software-Entwicklungsprozeß5 wird daher auch oft als
Software-Development-Life-Cycle bezeichnet. Dieser Software-Development-Life-Cycle
besteht aus mehreren Phasen. Jede dieser Phasen ist für sich ein eigener Prozeß. Im
folgenden Kapitel sollen die wichtigsten aus der Literatur bekannten SoftwareProzeßmodelle untersucht werden. Ein Software-Prozeßmodell beschreibt die Art und
Weise, wie die oben erwähnten Phasen des Software Development Life Cycles durchlaufen
werden. Das Software-Prozeßmodell ist ein wichtige Grundlage, um den Prozeß der
Software-Entwicklung und damit die Aufgaben der Projektplanung zu verstehen. Durch
die richtige Organisation des Software-Entwicklungsprozeß kann dessen Effizienz und
damit der Erfolg des Projektes gesteigert werden. [Pfl98]
5
engl.: Software Development Process
Kapitel 2: Projektplanung
7
2.3 Das Software-Prozeßmodell
Das erste Software-Prozeßmodell, das in der Literatur veröffentlicht wurde, ist das
Wasserfall-Modell (Royce 1970). Das Wasserfall-Modell stellt die einzelnen
Projektphasen als eine Reihenfolge von aufeinanderfolgenden Stufen dar. Wie Abbildung
2.1 zeigt, wird beim Wasserfall-Modell eine Projektphase abgeschlossen, bevor die nächste
Projektphase beginnt. [Pfl98]
Analysis
Design
Coding
Testing
Integration
Abbildung 2.1: Das Wasserfall-Modell beschreibt den Software-Entwicklungsprozeß als
eine Kette von abgeschlossenen Teilprozessen.
Das Wasserfall-Modell stellt den Software-Development-Life-Cycle in einem hohen
Abstraktionsgrad dar. Das größte Problem an diesem Modell ist, daß es den Prozeß der
Software-Entwicklung nicht so darstellt, wie er tatsächlich abläuft. In der Praxis läuft der
Software-Entwicklungsprozeß üblicherweise in einer großen Anzahl von Iterationen ab.
Die meisten Software-Komponenten, die heute entwickelt werden, sollen Probleme lösen,
für die zuvor noch keine Software-Lösung existiert hat. Weder der Auftraggeber, noch das
Entwicklungsteam kennen bereits am Projektbeginn alle Schlüsseleigenschaften und
Eckpunkte der angestrebten Software-Lösung. In der Praxis bewegt sich das
Entwicklungsteam daher zwischen den Projektphasen hin und her, um das Problem lösen
zu können.
Viele weitere Software-Prozeßmodelle, die seitdem entstanden sind, stellen nur eine
Erweiterung oder Modifikation des klassischen Wasserfall-Modells dar. Dazu gehören das
Wasserfall-Modell mit Prototyping, in der das klassische Wasserfall-Modell um eine
Prototyping-Phase erweitert wird. Aufgabe der Prototyping-Phase ist, einen Prototyp für
einen bestimmten Teilbereich des Systems zu erstellen. Ein Prototyp ist ein nur teilweise
entwickeltes Produkt, das es den Auftraggebern und Entwicklern ermöglicht, bestimmte
Aspekte des Systems zu untersuchen. Ein weiteres Software-Prozeßmodell, das ebenfalls
aus dem klassischen Wasserfall-Modell entstanden ist, ist das V-Modell. Das V-Modell
wurde vom deutschen Verteidigungsministerium 1992 veröffentlicht. Im V-Modell werden
die Analyse- und Designphase zur Testphase in Beziehung gesetzt. Abbildung 2.2 zeigt das
Schema des V-Modells. Anhand dieser Abbildung kann auch erkannt werden, wie dieses
Modell zu seinem Namen gekommen ist. [Pfl98]
Kapitel 2: Projektplanung
8
Integration
Analysis
überprüfe
Systemanforderungen
Acceptance
Testing
Design
überprüfe Design
System
Testing
Coding
Abbildung 2.2: Das V-Modell erzeugt Beziehungen zwischen den einzelnen Entwicklungsund Testphasen.
Ein weiteres Modell, das den Software Development Life Cycle zu beschreiben versucht,
ist das in Abbildung 2.3 dargestellte Prototyping-Modell. Das Prototyping-Modell baut auf
dem Prozeß des Prototypings als Grundlage auf. Der Prototyp erlaubt es, Teile des Systems
schnell zu implementieren, um bestimmte Systemeigenschaften verstehen und abklären zu
können. Während den einzelnen Phasen im Software-Entwicklugsprozeß wird der Prototyp
in mehreren Durchläufen schließlich bis zu einem fertigen System weiterentwickelt. In
jeder Phase wird der Prototyp durch gemeinsame Reviews so lange verfeinert, bis
schließlich das vom Auftraggeber erwünschte Systemverhalten erreicht wurde. [Pfl98]
Prototype
Requirements
revise prototype
Prototype
Requirements
Prototype
Design
Prototype
System
review
Prototype
Requirements
System Requirements
Prototype
Requirements
Test
System Requirements
Abbildung 2.3: Das Prototyping-Modell verwendet den Prozeß des Prototypings, um den
Software-Entwicklungsprozeß zu beschreiben.
Das letzte Software-Prozeßmodell, das in dieser Arbeit erwähnt werden soll, ist das SpiralModell. Dieses Modell betrachtet den Software-Development-Life-Cycle vom Standpunkt
des damit verbundenen Risikos. Das Spiral-Modell versucht den SoftwareEntwicklungsprozeß mit den Aufgaben des Risiko-Managements zu verbinden, um das
dabei vorhandene Risiko zu minimieren. Wie Abbildung 2.4 zeigt, beginnt das SpiralModell mit der Grobplanung des Entwicklungsprozesses. Dabei werden bereits das
vorhandene Budget, so wie die benötigten Tools und Mitarbeiter berücksichtigt. Mögliche
Alternativen und Einschränkungen müssen ebenfalls berücksichtigt werden. Im Prozeß
folgt nun eine erste Risikoanalyse und Prototyping-Phase, bevor ein Concept of OperationDokument erzeugt wird. Dieses Dokument beschriebt in einem hohen Abstraktionsgrad,
wie das fertige System Arbeiten soll. Dieses Dokument ist das „Produkt“ des ersten
Kapitel 2: Projektplanung
9
Entwicklungszyklus. Im zweiten Zyklus werden aus dem Concept of Operation-Dokument
die Anforderungen an das fertige System abgeleitet. Abermals erfolgt eine Betrachtung
möglicher Alternativen und Beschränkungen, sowie ein Risikoanalyse. Das Produkt des
zweiten Zuyklus sind schließlich die überprüften und vollständigen Systemanforderungen.
Im dritten Zyklus wird das Design beschrieben, der vierte Zyklus ermöglicht das Testen
des Systems. [Pfl98]
Determine goals,
alternatives, constraints
Evaluate alternatives
and risk
Risk analysis 4
Constraints4
Risk analysis 3
Constraints3
Risk analysis 2
Constraints2
Alternatives4
Constraints1
Alternatives3
Alternatives2
Budget4 Budget3
Budget1
Risk analysis 1
Alternatives1
Prototype1 Prototype2 Prototype3 Prototype4
Start
Budget1
Concept of
operation
Development
plan
Integration
ant test plan
Detailed
design
Softw are
requirements
Softw are
design
Code
Validated
requirements
Unit
Testing
Validated
design
System
testing
Plan
Acceptance
testing
Develop and test
Abbildung 2.4: Das Spiral-Modell stellt den Software-Entwicklungsprozeß in Form von
Entwicklungszyklen dar.
In jedem Entwicklungszyklus ist es Aufgabe der Risikoanalyse verschiedene Alternativen
unter Betrachtung möglicher Einschränkungen abzuwägen. Das Prototyping verifiziert die
Durchführbarkeit der Alternativen, bevor eine konkrete Möglichkeit ausgewählt wird.
Die Software-Prozeßmodelle, die in diesem Kapitel beschrieben wurden, sind nur einige
Beispiele für die unzähligen Modelle, die in der Literatur diskutiert und in der Praxis
eingesetzt werden. Neue Prozeßmodelle können definiert und an die Bedürfnisse des
Auftraggebers und des Entwicklungsteams angepaßt werden. Der tatsächliche Software
Development Life Cycle soll eher als eine Überlagerung mehrerer Prozeßmodelle gesehen
werden, als ein einzelnes konkretes Prozeßmodell. Alle Prozeßmodelle bestehen im
wesentlichen aus denselben Phasen, auch wenn diese im jeweiligen Prozeßmodell eine
andere Bezeichnungen erhalten.
Kapitel 2: Projektplanung
10
Laut [Boo92] kann der Software Development Life Cycle in folgende grundlegende
Phasen unterteilt werden:

Analysis - Systemanalyse und Requirements Specifcation

Design - Systementwurf

Coding - Implementierung

Testing - Testphase

Integration - Instandsetzung des Systems beim Kunden, Instandhaltung, Support
Diese Phasen bilden die Grundlage für die Projektplanung. Wie diese Phasen später im
Projektplan in eine zeitliche Reihenfolge gesetzt werden und in welcher Abhängigkeit die
einzelnen Phasen zueinander stehen, hängt von dem verwendeten Prozeßmodell ab. [Pfl98]
Auch der Software-Entwicklungsprozeß des in dieser Arbeit beschriebenen Projekts soll
nach einem der in diesem Abschnitt beschriebenen Prozeßmodelle erfolgen, um die
verschiedenen Aufgaben und Prozesse, die zur Umsetzung dieses Projekts notwendig sind,
besser strukturieren und kontrollieren zu können. Die Festlegung des Prozeß-Modells für
dieses Projekt erfolgt in Kapitel 2.5. Nachdem in diesem Abschnitt auf die wichtigsten in
der Literatur vorhandenen Prozeßmodelle eingegangen wurde, sollen im folgenden Kapitel
näher auf die Aufgaben der Projektplanung eingegangen werden.
2.4 Projektmanagement
Aufgabe des Projektmanagements ist, auf einem bestimmten Prozeß-Modell aufbauend,
den Projektablauf festzulegen und zu dokumentieren. Wie bereits in Kapitel 1.1 erwähnt
wurde, soll auch das in dieser Arbeit beschriebenen Projekt „hierarchische
Benutzerverwaltung unter Hyperwave“ nach den im folgenden Abschnitt beschriebenen
Methoden des Projektmanagements geplant werden, um eine erfolgreiche Durchführung
des Projekts garantieren zu können.
Ein typisches Projekt beginnt, wenn von einem Kunden die Entwicklung eines Systems in
Auftrag gegeben wird. Der Auftraggeber hat üblicherweise eine Menge von Fragen, die
beantwortet werden sollen: [Pfl98]

Versteht der Auftragnehmer die Probleme und die Bedürfnisse des Auftraggebers?

Kann der Auftragnehmer ein System entwerfen, das die Probleme löst und die
Bedürfnisse befriedigen kann?

Wie lange wird es dauern um ein solches System zu entwickeln?

Wie teuer wird die Entwicklung des System sein?
Vor allem um die letzten beiden Fragen beantworten zu können, muß das Projekt im Detail
geplant werden. In einem Projektplan wird der Software-Development-Life-Cycle des
durchzuführenden Projekts beschrieben, indem die Phasen des Projekts in einzelne
Aktivitäten und Schritte zerlegt werden. Der Projektplan dokumentiert die Interaktionen
zwischen diesen Aktivitäten und die Zeit, die jede einzelne Aktivität in Anspruch nehmen
Kapitel 2: Projektplanung
11
wird. Der Projektplan stellt auf einer Zeitlinie dar, wann die einzelnen Aktivitäten
beginnen und enden werden und wie diese Aktivitäten in Beziehung zueinander stehen.
Bei der Erstellung eines Projektplans muß zwischen Projektphasen und Meilensteinen
unterschieden werden. Projektphasen sind Teile des Projekts, die sich über eine gewisse
Zeitspanne erstrecken, während Meilensteine bestimmte Zeitpunkte im Projektablauf
festlegen. Um die Kosten für die Entwicklung des vom Auftraggeber gewünschten
Systems bereits am Projektbeginn abschätzen zu können, muß eine Aufwandsabschätzung
durchgeführt werden. Aufgabe der Aufwandsabschätzung ist, den Aufwand, der betrieben
werden muß, um das System umsetzten zu können, abzuschätzen. [Pfl98] Bevor in Kapitel
2.4.2 auf die Erstellung des Projektplans 2.4.3 auf Meilensteine eingegangen wird, soll
daher kurz der Vorgang der Aufwandsabschätzung beschrieben werden.
2.4.1 Aufwandsabschätzung
Einer der entscheidenden Faktoren in der Projektplanung ist die Abschätzung6 des
Projektaufwandes. Eine zu hohe Kosteneinschätzung kann zum Verlust des Auftrages
führen, eine zu geringe Kosteneinschätzung zu Verlusten in der eigenen Firma. Die Kosten
für ein Projekt setzen sich aus vielen Faktoren zusammen. Typische Kosten, die während
eines Projekts anfallen sind: Personalkosten, Reisekosten, Schulungskosten, Kosten für die
Infrastruktur, Kosten für Tools, usw. Die Aufwandsabschätzung muß bereits so früh wie
möglich im Software-Entwicklungsprozeß erfolgen. Während des Entwicklungsprozeß
sollten die veranschlagten Kosten regelmäßig überprüft werden, um etwaige Trends
erkennen zu können. [Pfl98]
In der Literatur existieren viele Methoden, die eine relativ exakte Aufwandsschätzung
ermöglichen. Dabei werden verschiedene Schätzmethoden unterschieden: Bei
Analogiemethoden wird der Schätzwert durch Vergleich mit ähnlichen, bereits
abgeschlossenen Projekten gewonnen. Bei der Prozentsatzmethode wird, abgeleitet von
früheren Projekten, die durchschnittliche prozentuale Aufwandsverteilung auf die
einzelnen Phasen als Schätzgrundlage verwendet. Dabei wird eine Phase detailliert
geschätzt und von diesem Teilaufwand auf den Gesamtaufwand geschlossen. Bei
parametrischen Schätzverfahren wird mittels statistischer Analyseverfahren versucht, aus
vorhandenen Projektdaten Einflußfaktoren zu gewinnen. Aus diesen Faktoren werden
Schätzgleichungen zusammengestellt, wobei der zugehörige Koeffizient die Stärke des
Einflusses des jeweiligen Faktors repräsentiert. Zu dieser Gruppe zählen die bereits
veraltete Schätzmethode COCOMO [CO99] und die heute sehr beliebte Function Point
Methode. [FP99]
Nachdem in dieser Arbeit nur sehr kurz auf das äußerst umfangreiche Thema
Aufwandsabschätzung eingegangen wurde, wird nun im nächsten Schritt, wie bereits
erwähnt die Erstellung von Projektplänen untersucht.
6
Eine wichtige Merkregel der Aufwandabschätzung besagt, daß nur jene Aufwände
geschätzt werden sollen, die nicht berechnet werden können! [Pfl98]
Kapitel 2: Projektplanung
12
2.4.2 Der Projektplan
Zur Erstellung von Projektplänen wird in der Praxis die Netzplantechnik verwendet. Die
Netzplantechnik ist eine systematische Vorgehensweise zur Erstellung eines Projektplans.
Diese Technik hilft dabei, Arbeitsschritte zu parallelisieren und somit die Projektdauer zu
verkürzen. Voraussetzung für eine mögliche Parallelisierung ist, daß die dazu benötigten
personellen Resourcen zur Verfügung stehen. Außerdem kann durch die Netzplantechnik
leicht der kritische Pfad eines Projektes gefunden werden. Der kritische Pfad ist jene Folge
von Projektschritten, bei denen die Verlängerung eines Projektschrittes zur Verlängerung
der gesamten Projektdauer führen würde. Da eine genaue Untersuchung der Netzplantechnik den Rahmen dieser Arbeit sprengen würde sei hier auf [NP99] verwiesen. Einen
Teil des Projektplans stellen die sogenannten Meilensteine dar. Meilensteine sind
Zeitpunkte, die spezielle Ereignisse im Projektverlauf markieren. Im folgenden Kapitel soll
die Bedeutung von Meilensteinen kurz beschrieben werden.
2.4.3 Meilensteine
Um den zeitlichen Ablauf des Projekts auch währen der Projektdurchführung kontrollieren
zu können, werden im Projektverlauf Meilensteine festgelegt. Tritt ein Meilenstein ein, so
wird überprüft, ob das Ziel des Projekts zu diesem Zeitpunkt und unter den vorliegenden
Umständen (Phasenziel erreicht, bzw. nicht erreicht) noch erreicht werden kann. Kann ein
Meilenstein nicht zum festgelegten Termin erreicht werden, oder treten technische
Komplikationen während der Implementierung auf, so müssen entsprechende Maßnahmen
getroffen werden, um das Projektziel (Termin, Funktionen, Kosten) unter den gegebenen
Umständen wieder erreichen zu können. Meilensteine werden vorzugsweise an den
Grenzen zwischen Projektphasen festgelegt. Anhand von Meilensteinen kann der
Fortschritt eines Projekts gemessen werden. [Boo92]
Nachdem nun die wichtigsten Begriffe der Projektplanung geklärt wurden, soll am Ende
dieses Kapitels die Projektplanung des Projekts „Hierarchische Benutzerverwaltung unter
Hyperwave“ durchgeführt werden.
2.5 Projektplanung am Beispiel der
hierachischen Benutzerverwaltung
Auch die Planung des in dieser Arbeit beschriebene Projekts „hierarchische
Benutzerverwaltung unter Hyperwave“ soll nach den in Kapitel 2.4 beschriebenen
Methoden des Projektmanagements erfolgen, um eine erfolgreiche Durchführung des
Projekts garantieren zu können. Im ersten Schritt soll daher das Prozeß-Modell, an dem
sich der Software-Entwicklungsprozeß dieses Projekts richtet, festgelegt werden.
Als Prozeßmodell für das Projekt „Hierarchische Benutzerverwaltung unter Hyperwave“
wird das Wasserfall-Modell dienen (siehe auch Kapitel 2.3). Trotz der Schwächen des
Wasserfall-Modells ist dieses Prozeßmodell am besten für das Projekt „Hierarchische
Benutzerverwaltung unter Hyperwave“ geeignet.
Kapitel 2: Projektplanung
13
Folgende Gründe sind dafür ausschlaggebend:

Das Projekt „Hierarchische Benutzerverwaltung unter Hyperwave“ ist ein sehr kleines
Projekt und erfordert daher auch eine möglichst einfache Projektplanung, die durch das
Wasserfall-Modell gewährleistet ist.

Das Wasserfall-Modell beschreibt sehr anschaulich, welche Schritte unternommen
werden müssen, um ein Projekt durchzuführen. An diesen Schritten kann sich das
Projekt „Hierarchische Benutzerverwaltung unter Hyperwave“ orientieren.
Dadurch diese Wahl ergeben sich die in Tabelle 2.1 angeführten Projektphasen, die auch
die nachfolgende Kapitelstruktur widerspiegelt. Die genauen Aufgaben jeder einzelnen
Phasen werden am Beginn des jeweiligen Kapitels beschrieben.
Phasenbezeichnung
Kapitel
Analysis
Kapitel 3, Requirements Specification
Kapitel 4, Hyperwave – ein Überblick
Kapitel 5, Lösungssuche
Design
Kapitel 6, Technischer Entwurf der ausgewählten Variante
Coding
Kapitel 7, Die Implementierungsphase
Testing
Kapitel 8, Testphase
Integration
Kapitel 9, Integration
Tabelle 2.1: Projektphasen für das Projekt „Hierarchische Benutzerverwaltung unter
Hyperwave“
Im Folgenden wird die Planung des Projekts „Hierarchische Benutzerverwaltung unter
Hyperwave“ vorgenommen. Bestimmte Informationen in der Projektplanung, die sensible
Daten preisgeben würden, wurden anonymisiert oder werden im Rahmen der vorliegenden
Arbeit nicht angegeben. Die in dieser Arbeit dargestellte Projektplanung soll nur das
prinzipielle Vorgehen aufzeigen und dokumentieren.
2.5.1 Aufwandsabschätzung
Die Aufwandsabschätzung (siehe auch Kapitel 2.4.1) der in Kapitel 2.5 festgelegten
Projektphasen erfolgt nur in einem groben, exemplarischen Maßstab. Die Schätzung wurde
unabhängig von zwei Personen basierend auf Erfahrungswerten aus ähnlichen Projekten
vorgenommen. Tabelle 2.2 zeigt die für das Projekt „hierarchische Benutzerverwaltung“
vorgenommene Aufwandsabschätzung in einer Übersicht. Eine Unterteilung der
Projektphasen in einzelne Teilprozesse, sowie eine detaillierte Aufwandsabschätzung
dieser Teilprozesse erfolgt in Tabelle 2.3 bis Tabelle 2.6.
Kapitel 2: Projektplanung
14
Projektphase
Aufwand [in Tagen]
01
Analyse
40
02
Design
20
03
Implementierung
50
04
Test
20
05
Abnahme
5
Tabelle 2.2: Aufwandsabschätzung für das Projekt „hierarchische Benutzerverwaltung
unter Hyperwave“.
a) Analysephase
Aufgabe der Analysephase ist, eine konkrete Möglichkeit zu finden, um ein System zur
hierarchische Benutzerverwaltung auf einem Hyperwave Information Server umsetzen zu
können. Nachdem die Systemanforderungen an eine hierarchische Benutzerverwaltung
festgelegt werden, sollen daher die Eigenschaften des Hyperwave Information Servers
analysiert werden. Um eine geeignete Lösung finden zu können, sollen auch bereits
existierende Systeme in Hinblick auf eine hierarchische Benutzerverwaltung untersucht
werden. Tabelle 2.3 zeigt eine Aufgliederung der Aufwandsabschätzung der Analysephase.
Teilprozeß
Aufwand [in Tagen]
Systemanforderungen
5
Analyse des Hyperwave-Servers
15
Analyse bestehender Systeme
12
Lösungssuche
8
Tabelle 2.3: Aufwandsabschätzung der Teilprozesse in der Analysephase.
b) Designphase
In der Designphase soll das in der Analysephase abgeleitete System zur Umsetzung einer
hierarchischen Benutzerverwaltung im Detail geplant werden. Der Entwurf des
notwendigen Programmcodes soll nach den Methoden des Objektorientierten
Programmierens erfolgen. Diese Objekt sollen in die am IICM entwickelte
Objektbibliothek hwlib7 eingebunden werden. Die Design-Phase besteht aus den in
7
siehe Kapitel 6.7
Kapitel 2: Projektplanung
15
Tabelle 2.4 aufgegliederten Teilprozessen.
Teilprozeß
Aufwand [in Tagen]
Entwurf der Benutzerdialoge
3
Objektortieter Entwurf
10
Einbindung in hwlib
1
Entwurf des Wavemaster-Templates
6
Tabelle 2.4: Aufwandsabschätzung der Teilprozesse in der Designphase.
c) Implementierungsphase
Die Aufwände der Implementierungsphase können erst genau geschätzt werden, wenn die
genaue Struktur (Objekte, Dialoge, usw.) des zu implementierenden Codes nach
Durchführung der Designphase bekannt ist. Die detaillierte Aufwandsabschätzung der
Implementierungsphase erfolgt daher erst in Kapitel 6.13.
d) Testphase
In der Testphase wird die Korrektheit des implementierten Programmcodes überprüft. Die
Testphase kann nach Pfleeger [Pfl98] in die in Tabelle 2.5 angeführten Teilprozesse
unterteilt werden: In der Phase Unit-Testing wird die Funktionalität der umgesetzten
Objekte auf ihre Korrektheit überprüft. Aufgabe des Integration-Testings ist das korrekte
Zusammenspiel der Objekte in den zur Umsetzung einer hierarchischen
Benutzerverwaltung benötigten Programmodulen zu verifizieren. In der Phase des SystemTestings wird schließlich das Verhalten des Gesamtsystems auf seine Korrektheit
überprüft.
Teilprozeß
Aufwand [in Tagen]
Unit-Testing
6
Integration Testing
2
System-Testing
12
Tabelle 2.5: Aufwandsabschätzung der Teilprozesse in der Testphase.
e) Abnahmephase
Kapitel 2: Projektplanung
16
Aufgabe der Abnahmephase ist die fertiggestellte Software beim Auftraggeber zu
installieren. Tabelle 2.6 zeigt den Aufwand der Teilprozesse in der Abnahmephase.
Teilprozeß
Aufwand [in Tagen]
Installation beim Auftraggeber
2
Tabelle 2.6: Aufwandsabschätzung der Teilprozesse in der Abnahmephase.
Bevor am Ende dieses Abschnitts der Projektplan für das Projekt „hierarchische
Benutzerverwaltung unter Hyperwave“ erstellt wird, werden im nächsten Abschnitt die
Meilensteine für dieses Projekts definiert. Meilensteine sind ein wichtiges Mittel, um den
Projektfortschritt messen zu können.
2.5.2 Meilensteine
Meilensteine (siehe auch Kapitel 2.4.3) werden vorzugsweise an den Grenzen zwischen
Projektphasen festgelegt. Anhand von Meilensteinen kann der Fortschritt eines Projekts
gemessen werden. [Boo92] Tabelle 2.7 zeigt die Meilensteine, die für die Durchführung
dieses Projekts festgelegt wurden.
Meilenstein
M1
Analysephase abgeschlossen
M2
Designphase abgeschlossen
M3
Implementierungsphase abgeschlossen
M4
Projektende
Tabelle 2.7: Meilensteine des vorliegenden Projekts
2.5.3 Projektplan
Aufgabe des Projektplans ist, die einzelnen Projektphasen in eine zeitliche Reihenfolge zu
setzten. Da für die Durchführung des Projekts „Hierarchische Benutzerverwaltung unter
Hyperwave“ nur eine Person vorgesehen ist, können die einzelnen Projektschritte nur in
sequentieller Reihenfolge abgearbeitet werden. Parallelisierung, um die Dauer des Projekts
zu verkürzen ist daher nicht möglich. Für die Planung dieses Projekts wird daher auch nur
eine sehr vereinfachte Form der Netzplantechnik verwendet. Im folgenden wird
schrittweise die Erstellung des Projektplans vorgenommen.
Die im folgenden angeführten Schritte wurden der Netzplantechnik (siehe auch Kapitel
2.4.2) entnommen:
Kapitel 2: Projektplanung
17
Schritt 1:
Im ersten Schritt werden alle Phasen des Projekts und ihre voraussichtliche Dauer
aufgelistet. Die Unterteilung der Projektphasen für das Projekt „Hierarchische
Benutzerverwaltung unter Hyperwave“ können Tabelle 2.2 (siehe Kapitel 2.5.1)
entnommen werden.
Schritt 2:
Im zweiten Schritt werden die Abhängigkeiten der einzelnen Projektphasen voneinander
festgelegt. Dies geschieht durch Festlegen der Anordnungsbeziehungen (AOB). Dabei
wird der Nachfolger jeder einzelnen Projektphase bestimmt. In Tabelle 2.8 sind die
Anordnungsbeziehungen für das Projekt „Hierarchische Benutzerverwaltung unter
Hyperwave“ angeführt.
Projektphase
Nachfolger
01
Analyse
02
02
Design
03
03
Implementierung
04
04
Test
05
05
Abnahme
-
Tabelle 2.8: Die AOB bestimmen die Nachfolger jeder einzelnen Projektphase.
Laut der Netzplantechnik würden jetzt noch eine Reihe weitere Schritte folgen, um den
kritischen Pfad des Projekts feststellen zu können. Da der kritische Pfad in diesem Projekt
aber durch die sequentielle Durchführung der Projektphasen von vornherein gegeben ist,
soll auf diese weiteren Schritte verzichtet werden. Als Abschluß der Projektplanung wird
in Abbildung 2.5 der Projektplan im Gantt-Diagramm dargestellt.
Projektplan
1998
1999
Netinfo
10
Projektphasen
01
06
03
04
05
Analyse
Design
Implementierung
Test
Abnahme
Meilensteine
M1
M2
Analyse
M3
M4
Implementation
Design
Projektende
11
12
01
02
03
04
05
Kapitel 2: Projektplanung
18
Abbildung 2.5: Der Projektplan des Projekts „hierarchische Benutzerverwaltung unter
Hyperwave“
2.6 Schlußbemerkung
In Kapitel 2 wurde auf die Projektplanung eingegangen. Die Projektplanung ist ein
unumgängliches Werkzeug, um einen erfolgreichen Projektverlauf sicherzustellen. Daher
muß auch für das in dieser Arbeit beschriebene Objekt „hierarchische Benutzerverwaltung
unter Hyperwave“ eine Projektplanung durchgeführt werden. Aufgabe der Projektplanung
ist es, die einzelnen Arbeitsschritte des Software-Entwicklungsprozeß in eine zeitliche
Reihenfolge zu bringen. Um die Aufgaben der Projektplanung besser verstehen zu können,
wurden am Beginn dieses Kapitels die Eigenschaften von Prozessen genauer untersucht. Es
wurde festgestellt, daß ein Prozeß einer geordneten Reihenfolge von bestimmten
Tätigkeiten entspricht. In Kapitel 2.3 wurden verschiedene Software-Prozeßmodelle
vorgestellt, die versuchen, den Software-Entwicklungsprozeß zu strukturieren. Das älteste
Software-Prozeßmodell ist das Wasserfall-Modell, das den Software-Entwicklungsprozeß
sehr vereinfacht darstellt. Weitere wichtige Prozeßmodelle sind das Prototyping-Modell
und das Spiral-Modell, bei dem die Projektphasen als Entwicklungszyklen bezeichnet
werden und das Risiko-Management in die Projektplanung mit einbezogen wird. Die
Durchführung des in dieser Arbeit beschriebenen Projekts soll nach dem WasserfallModell erfolgen. Dieses Modell ist für die vorliegende Arbeit am Besten geeignet, da es
den Software-Entwurfsprozeß sehr übersichtlich und einfach darstellt.
Eine weitere Aufgabe der Projektplanung ist, eine Aufwandsabschätzung für das Projekt
durchzuführen. In der Literatur sind verschiedene Schätzmethoden bekannt. Eine
Schätzmethode, die allerdings die Hinzuziehung eines eigenen Experten benötigt, ist die
Function-Point-Methode. Die Aufwandsabschätzung des in der vorliegenden Arbeit
beschriebenen Projekts „hierarchische Benutzerverwaltung unter Hyperwave“ soll nach der
Analogiemethode vorgenommen werden. Dabei werden bereits ähnliche, bereits
abgeschlossene Projekte als Grundlage zur Aufwandsermittlung herangezogen. Danach
wurde noch kurz auf die Aufgabe von Meilensteinen und die Erstellung von Projektplänen
eingegangen. Am Ende dieses Kapitels wurde die Projektplanung für das Projekt
„Hierarchische Benutzerverwaltung unter Hyperwave“, das in dieser Arbeit beschrieben
wird, vorgenommen, um eine erfolgreiche Durchführung dieses Projekts sichern zu
können.
Mit dem nächsten Kapitel dieser Arbeit beginnt die Umsetzung des Projektes
„hierarchische Benutzerverwaltung unter Hyperwave“ nach dem in Kapitel 2.5.3
festgelegten Projektplan. Zu Beginn der ersten Projektphase, der Analysephase, müssen im
ersten Schritt die Anforderungen an ein System zur hierarchischen Benutzerverwaltung
festgelegt werden. Diese „Requirements Specifications“ bilden die Grundlage für alle
weiteren Schritte, die im Rahmen dieses Projekts durchgeführt werden. Zugleich beginnt
mit dem nächsten Kapitel auch der Untersuchungsbereich der vorliegenden Arbeit. Im
Untersuchungsbereich soll analysiert werden, welche Eigenschaften ein System zur
hierarchischen Benutzerverwaltung unter Hyperwave aufweisen muß. Danach sollen
verschiedene Möglichkeiten und Konzepte, sowohl bestehender als auch eigener Lösungen
Kapitel 2: Projektplanung
19
analysiert werden, um daraus am Ende des Untersuchungsbereiches schließlich ein System
zur hierarchische Benutzerverwaltung unter Hyperwave ableiten zu können.
Untersuchungsbereich
Mit dem folgenden Kapitel beginnt der Untersuchungsbereich der vorliegenden Arbeit.
Ziel des Untersuchungsbereichs ist, aus den sehr vagen und ungenau formulierten
Vorgaben des Auftraggebers ein konkretes Konzept für die Umsetzung einer
hierarchischen Benutzerverwaltung unter Hyperwave abzuleiten. Wie in Kapitel 2.5
festgelegt wurde, soll der Software-Entwicklungsprozeß des in dieser Arbeit beschriebenen
Projekts nach dem Wasserfall-Modell erfolgen. Außerdem sollen im Untersuchungsbereich
die in Kapitel 2.4 untersuchten Methoden des Projektmanagements nach Pfleeger [Pfl98]
eingesetzt werden, um ein erfolgreiche Durchführung des Projekts erreichen zu können.
Der Untersuchungsbereich bildet die Grundlage für die Umsetzung der hierarchischen
Benutzerverwaltung im Gestaltungsbereich. Der Untersuchungsbereich soll immer
möglichst umfangreich und weitblickend gefaßt sein, um eine Vielzahl von möglichen
Lösungsalternativen zu erhalten, aus denen schließlich am Ende eine konkrete Lösung
abgeleitet werden kann. [Pfl98]
Kapitel 3
Requirements Specification
"..., we must analyze the problem, before we consider any solution."8 [Pfl98, S.137.]
3.1 Einleitung
Im ersten Schritt des Untersuchungsbereiches sollen an dieser Stelle die Anforderungen an
ein System zur hierarchischen Benutzerverwaltung unter Hyperwave untersucht werden.
Mit der Analyse der Systemanforderungen, die in diesem Kapitel erfolgen soll, beginnt die
Umsetzung des Projekts „hierarchische Benutzerverwaltung unter Hyperwave“ nach dem
in Kapitel 2.5.3 festgelegten Projektplan.
Die Ausgangssituation am Beginn eines Projekts ist eine sehr kritische Phase. Der
Auftraggeber hat bereits jetzt genaue Vorstellungen davon, welche Funktionalität die
Softwarekomponente besitzen soll. Meist existieren in dieser Phase eines Projekts aber nur
vage Daten aus mündlichen Gesprächen oder unstrukturierten schriftlichen Dokumenten,
welche die notwendige Funktionalität der Softwarekomponente beschreiben. Der
Auftraggeber und der Softwareexperte sprechen in ihren eigenen Jargons und glauben oft
dasselbe zu meinen, reden aber über grundverschiedene Dinge. Mißverständnisse währen
dieser Phase führen zu Softwarekomponenten, die schlichtweg das falsche Problem lösen,
die nicht die gewünschte Funktionalität besitzen, oder für den Anwender schwer zu
verstehen und zu benutzen sind. [Pfl98]
Um so gravierende Mißverständnisse zu vermeiden, müssen am Beginn des Projekts die
Anforderungen an das zu entwickelnde System gemeinsam mit dem Auftraggeber
erarbeitet und dokumentiert werden. Das Umfeld, in dem das System eingesetzt werden
soll, muß analysiert werden. [Pfl98] Dieser Prozeß wird in der Terminologie des
Projektmanagements als Teil der Analysephase betrachtet (siehe auch Kapitel 2
„Projektplanung“).
Im diesem Kapitel wird untersucht, welche Ziele durch den Einsatz einer hierarchischen
Benutzerverwaltung erreicht werden sollen. Nach einer Analyse des Umfeldes, in dem die
8
"...wir müssen das Problem analysieren, bevor wir irgendeine Lösung in Betracht
ziehen." [Pfl98]
Kapitel 3: Requirements Specification
22
hierarchische Benutzerverwaltung zum Einsatz kommen wird und einer Analyse der
Probleme, die durch den Einsatz dieser Softwarekomponente gelöst werden sollen, können
schließlich die Anforderungen an das System abgeleitet werden. Diese
Systemanforderungen dienen als Ausgangspunkt und Grundlage für alle weiteren
Untersuchungen.
3.2 Analyse des Umfelds
Ein großer deutscher Elektronik-Konzern hat zur Erstellung von Produktbeschreibungen
im Consumer-Bereich (Handies, Küchengeräte, usw.) gemeinsam mit dem IICM9 Graz
eine auf Hyperwave basierende Intranetlösung konzipiert. Um Produktbeschreibungen
einheitlich und rasch erstellen zu können, wird für jede Produktgruppe eine sogenannte
Produktvorlage erstellt. Eine Produktvorlage entspricht einem Satz von Templates, die nur
mehr mit den entsprechenden produktspezifischen Informationen gefüllt werden müssen.
Jedem Produkt ist ein Team von Projektadministratoren, Autoren und solchen Benutzern,
die nur lesend auf die Produktbeschreibung zugreifen dürfen, zugeordnet. Die
Projektadministratoren erstellen an Hand einer Produktvorlage gemeinsam mit den
Autoren eine konkrete Produktbeschreibung für ein bestimmtes Produkt.
Auf Grund der breiten Produktpalette dieses Konzerns werden in diesem System derzeit
bereits über eintausend Benutzer administriert10. Die Systemadministratoren dieses
Intranetsystems mit dem Namen NetInfo haben die Aufgabe, neue Benutzer anzulegen,
gegebenenfalls Benutzerdaten zu ändern, Benutzer aus dem System zu löschen und die
Benutzer den einzelnen Projektteams zuzuordnen. Die Verwaltung dieser großen Anzahl
von Benutzern belastet die Systemadministratoren mit großem zeitlichen Aufwand. Diese
Belastung soll durch Einsatz einer hierarchischen Benutzerverwaltung verhindert werden.
Aus dieser kurzen Beschreibung der Umgebung, in der die hierarchische
Benutzerverwaltung zum Einsatz kommen wird, lassen sich bereits zwei wesentliche
Eigenschaften ablesen, die von der hierarchischen Benutzerverwaltung erfüllt werden
müssen:

Die hierarchische Benutzerverwaltung muß in einer sehr "benutzerintensiven"
Umgebung arbeiten.

Die Benutzerverwaltung muß die Struktur der Projektgruppen berücksichtigen
(Projektleiter, Autoren, normale Benutzer).
Nachdem in diesem Kapitel das Umfeld, in dem die hierarchische Benutzerverwaltung
zum Einsatz kommen wird, analysiert wurde, wird im nächsten Schritt auf die Probleme
eingegangen, die durch die hierarchische Benutzerverwaltung gelöst werden müssen.
9
Institut für Informationsverarbeitung und Computergestützte neue Medien, TU-Graz
10
Die Anzahl der administrierten Benutzer ist aus der Erfahrung des Auftraggebers
weiterhin im Steigen begriffen.
Kapitel 3: Requirements Specification
23
3.3 Problemanalyse
Für das Netinfo-System sollen die bereits bestehenden Dialoge zur Benutzerverwaltung so
adaptiert werden, daß sich damit eine hierarchische Benutzerverwaltung durchführen läßt.
Die Prozesse, die beim Anlegen, Ändern und Löschen von Benutzern auftreten sind daher
bereits bekannt. Die Dialoge und Funktionen der bereits bestehende Benutzerverwaltung
müssen nur um die „hierarchischen“ Eigenschaften erweitert werden. Zusammenfassend
können folgende Probleme festgestellt werden, die durch die hierarchische
Benutzerverwaltung gelöst werden müssen:
1) Die Systemadministratoren werden durch die große Benutzeranzahl zusätzlich belastet.
Da die Anzahl der Systemadministratoren in einem System immer möglichst klein
gehalten werden soll, muß ein Weg gefunden werden, die Systemadministratoren zu
entlasten, ohne deren Anzahl zu erhöhen.
2) Die von den Systemadministratoren durchgeführte Benutzerverwaltung arbeitet sehr
langsam. Für jede Aufgabe aus der Benutzerverwaltung, wie Anlegen eines neuen
Benutzers für das NetInfo-System, muß von dem Leiter des Projektteams - dem
Projektadministrator - ein Antrag an die Systemadministratoren gestellt werden. Die
Zeitspanne, die zwischen dem Zeitpunkt der Anforderung und dem Zeitpunkt der
tatsächlichen Durchführung durch die Systemadministratoren vergeht, erzeugt unnötige
Wartezeiten. Dieses Problem muß durch die hierarchische Benutzerverwaltung gelöst
werden.
3) Auf die große Anzahl der Benutzer muß bei der Erstellung der Dialoge für die
hierarchische Benutzerverwaltung Rücksicht genommen werden. Es muß möglich sein,
trotz der großen Benutzeranzahl effizient mit der Benutzerverwaltung zu arbeiten.
Vor allem Punkt 1 und Punkt 2 zeigen die grundlegenden Probleme, die durch die
hierarchische Benutzerverwaltung gelöst werden müssen. Nachdem die Umgebung, in der
die hierarchische Benutzerverwaltung zu Einsatz kommen wird und die zu lösenden
Probleme analysiert wurden, können daraus nun im nächsten Schritt die Anforderungen an
die hierarchische Benutzerverwaltung abgeleitet werden.
3.4 Systemanforderungen
Das Festlegen der Systemanforderungen erfüllt mehrere Aufgaben. Die wichtigste Aufgabe
ist, dadurch gemeinsam mit dem Auftraggeber abzuklären, welche Eigenschaften die zu
entwickelnde Softwarekomponente haben soll. Eine weitere Aufgabe der
Systemanforderungen ist, die Eigenschaften der Softwarekomponente zusammenzufassen
und somit als Grundlage für die Designphase zu dienen (siehe Kapitel 6, „ Technischer
Entwurf der ausgewählten Variante“). Außerdem wird durch die Systemanforderungen
bestimmt, wie das fertiggestellte System auf Eingaben reagieren muß. Daher dienen die
Systemanforderungen auch als Referenz für die Erstellung von Testdatensätzen in der
Testphase des Systems (siehe Kapitel 8).
Kapitel 3: Requirements Specification
24
Es werden zwei Arten von Systemanforderungen unterschieden: [Pfl98]
1) Die funktionalen Systemanforderungen beschreiben Interaktionen des Systems mit
seiner Umgebung. Es wird festgelegt, wie das System auf bestimmte Eingaben
reagieren muß.
2) Die nichtfunktionalen Systemanforderungen beschreiben allgemeine Eigenschaften des
Systems, wie z. B. Systemsicherheit, Performance und Benutzerfreundlichkeit.
Die Systemanforderungen an die hierarchische Benutzerverwaltung wurden gemeinsam
mit dem Auftraggeber dieses Projekts in einem Pflichtenheft erarbeitet. Dieses
Pflichtenheft ist nicht Bestandteil dieser Arbeit. Im wesentlichen entsprechen die darin
vereinbarten
Anforderungen
aber
den
in
diesem
Kapitel
angeführten
Systemanforderungen. Im nächsten Schritt dieser Arbeit werden die funktionalen
Systemanforderungen an die hierarchische Benutzerverwaltung beschrieben. Nachdem die
funktionalen Systemanforderungen vollständig dokumentiert wurden, wird auf die
nichtfunktionalen Systemeigenschaften der hierarchischen Benutzerverwaltung
eingegangen. Die Sammlung von Funktionen und Dialogen, welche die in den
Systemanforderungen zusammengefaßte Funktionalität umsetzen, werden in der
vorliegenden Arbeit nachfolgend mit dem Begriff hierarchische Benutzerverwaltung
bezeichnet.
3.4.1 Funktionale Systemanforderungen
Die Funktionalen Systemanforderungen beschreiben das System, ohne auf konkrete
Implementierungskriterien des Systems, wie die verwendete Programmiersprache oder
benutzte Datenstrukturen einzugehen. [Pfl98] Auf den folgenden Seiten dieser Arbeit
werden die funktionalen Systemanforderungen an die hierarchische Benutzerverwaltung
beschrieben. Zur besseren Übersicht werden die einzelnen Aspekte der hierarchischen
Benutzerverwaltung in Unterpunkte gegliedert.
Projektadministratoren
Die Benutzerverwaltung soll einer speziellen Gruppe von Benutzern zugeordnet werden,
die zwischen den Systemadministratoren und jenen Benutzern des Systems steht, die keine
Systemrechte besitzen. Diese Gruppe wird als die Gruppe der Projektadministratoren
bezeichnet. Projektadministratoren haben, wie bereits erwähnt, zwar keine Systemrechte,
jedoch haben sie das Recht, neue Benutzer in gewissen Bereichen anzulegen, bzw. bereits
bestehende Benutzer zu editieren und zu löschen.
Informationsräume
Um zu gewährleisten, daß die Projektadministratoren nicht ihre Kompetenzen
überschreiten können und sich gegenseitig bzw. andere Benutzer, die nicht ihrem
Projektbereich zugeordnet sind, aus dem System löschen, werden Bereiche festgelegt, die
den einzelnen Projektadministratoren zugeordnet sind. Nur in diesem Bereich dürfen die
Kapitel 3: Requirements Specification
25
Projektadministratoren Benutzer erzeugen, editieren und löschen. Diese Bereiche werden
Informationsräume genannt und als solche nachfolgend bezeichnet.
Hierarchiestufen
Die Informationsräume sollen zur besseren Übersicht hierarchisch geordnet werden. Durch
die hierarchische Anordnung werden die Informationsräume von einer Hierarchieebene zur
nächsten immer feiner unterteilt. Außerdem kann durch die hierarchische Unterteilung
gewährleistet werden, daß Projektadministratoren, die sich auf einer höheren
Hierarchiestufe befinden immer auf alle darunterliegenden Bereiche Zugriff haben.
Projektadministratoren, die sich auf einer untergeordneten Hierarchiestufe befinden,
können keinen Schaden anrichten, indem sie ihre Kompetenzen überschreiten und
Benutzereinträge ändern oder löschen, die sich außerhalb ihres Projektbereiches und damit
ihres Kompetenzbereiches befinden. Die Informationsräume spiegeln die interne
Abteilungsstruktur des Konzerns wider. Zum Beispiel darf der Projektadministrator, der
für den Informationsraum Handies verantwortlich ist, neue Projektadministratoren
erzeugen und sie den neuen Informationsräumen Handies/GSM und Handies/DualBand
zuordnen. Er darf jedoch keinen Projektadministrator für den Bereich Faxgeräte
erzeugen, da sich dieser Informationsraum außerhalb seines Projektbereichs befindet. Die
Projektadministratoren der Informationsräume Handies/GSM und Handies/DualBand
dürfen ihrerseits wieder neue Projektadministratoren erzeugen und natürlich auch
"normale" Benutzer, jedoch nur in den ihnen zugeordneten Informationsräumen. Auf diese
Benutzer hat auch der Projektadministrator des Bereichs Handies" Zugriff. Jedoch haben
die Projektadministratoren der Bereiche Handies/GSM und Handies/DualBand weder
Zugriff auf Benutzer, die der Projektadministrator des Bereichs Handies erzeugt, noch auf
den Projektadministrator selbst.
Benutzerrollen
Im Netinfo-System sind drei unterschiedliche Gruppen von Benutzern vorgesehen:

Projektadministratoren haben das Recht neue Benutzer in untergeordneten Bereichen
zu erzeugen. Die neu erzeugten Benutzer dürfen wiederum Projektadministratoren,
Autoren, oder normale Benutzer sein. Projektadministratoren haben alle Rechte, die
auch Autoren besitzen.

Autoren dürfen Dokumente am Server editieren und löschen. Autoren besitzen alle
Rechte, die auch normale Benutzer haben.

Normale Benutzer dürfen nur lesend auf Dateien zugreifen.
Diese drei unterschiedlichen Berechtigungen werden mit den Buchstaben P für
Projektadministrator, A für Autor und R11 für „normaler“ Benutzer abgekürzt. Die
Berechtigung eines Benutzers wird durch das Attribut User_Role im entsprechenden
Benutzerobjekt festgehalten. Durch die Benutzerrolle wird auch entschieden, welche
11
normale Benutzer werden in der Infomed-Terminologie als Reader bezeichnet
Kapitel 3: Requirements Specification
26
Benutzer die hierarchische Benutzerverwaltung benutzen dürfen. Der Menüpunkt zur
hierarchischen Benutzeradministration ist nur verfügbar, wenn der Benutzer als
Systembenutzer oder als Benutzer mit User_Role=P im System identifiziert ist.
Vorgesehene Attribute für Benutzer- und Gruppenobjekte
Die notwendigen Attribute für die hierarchische Benutzerverwaltung sollen in den
Benutzer- und Gruppenobjekten des Hyperwave Information Servers gespeichert werden.
Es wird zwischen notwendigen und wahlfreien Attributen unterschieden. Wahlfreie
Attribute brauchen nicht notwendigerweise einen Wert zu besitzen. Tabelle 3.1 zeigt alle
Attribute, die für Benutzerobjekte definiert wurden. Ein Benutzerobjekt kann nur angelegt
bzw. editiert werden, wenn alle notwendigen Attribute einen Wert besitzen.
Bezeichnung deutsch
Bezeichnung englisch
Name
Nachname
Last Name
Last_Name
notwendig
Vorname
First Name
First_Name
notwendig
Login
Login
Uname
notwendig
Paßwort
Password
Passwd
notwendig
Dienststelle
Department
Department
notwendig
Telefon
Phone
Phone
notwendig
User Rolle
User Role
User_Role
notwendig
Informationsraum
Info Space
Info_Space
notwendig
Gruppe
Group
Group
notwendig
Verantwortlich
User Administrator
Author
notwendig
Org-Einheit
Organisation
Organisation
wahlfrei
Vorwahl
Area_Code
Area_Code
wahlfrei
Firmenvorwahl
Company Code
Company_Code
wahlfrei
E-Mail
E-Mail
Email
wahlfrei
Standort
Location
Location
wahlfrei
MA-Indent
MA-Ident
MA_Ident
wahlfrei
Beschreibung
Description
Descr
wahlfrei
Tabelle 3.1: Attribute, die Benutzerobjekte im Netinfo-System besitzen können.
Kapitel 3: Requirements Specification
27
Die Zuordnung zu den Informationsräumen erfolgt durch das Attribut Info_Space. Dieses
Attribut bestimmt auch den Bereich, in dem ein Projektadministrator eingeschränkt
Benutzer- und Gruppenobjekte verwalten darf.
Im Rahmen der hierarchischen Benutzerverwaltung soll Projektadministratoren auch die
Möglichkeit geboten werden, neue Gruppenobjekte am Server anzulegen. Dadurch können
Projektadministratoren die von ihnen angelegten Benutzerobjekte zur besseren
Übersichtlichkeit zu Gruppen zusammenfassen. Diese Gruppen müssen natürlich auch den
Gesetzen der hierarchischen Benutzerverwaltung unterliegen. Gruppenobjekte können im
Netinfo-System die in Tabelle 3.2 aufgelisteten Attribute besitzen. Eine neue Gruppe kann
nur angelegt werden, wenn alle notwendigen Attribute gesetzt sind.
Bezeichnung deutsch
Bezeichnung englisch
Name
Gruppenname
Group Name
Ugroup
notwendig
Informationsraum
Info Space
Info_Space
notwendig
Verantwortlicher
User Administrator
Author
notwendig
Beschreibung
Description
Descr
notwendig
Tabelle 3.2: Auch Gruppenobjekte werden in die hierarchische Benutzerverwaltung
eingebunden.
Funktionen und Dialoge
Die Dialoge und Funktionen, die im Rahmen der hierarchischen Benutzerverwaltung
angeboten werden, können in drei Funktionsgruppen unterteilt werden. Die
Funktionsgruppe „Benutzerobjekte anlegen, editieren und löschen“ beinhaltet all jene
Funktionen und Dialoge, die zur Verwaltung von Benutzerobjekten im Rahmen der
hierarchischen Benutzerverwaltung vorgesehen sind. Unter der Funktionsgruppe
„Gruppenobjekte anlegen, editieren und löschen“ werden alle Funktionen und Dialoge zur
Verwaltung von Gruppenobjekten zusammengefaßt. Die Funktionsgruppe „Benutzer zu
Gruppen zuordnen“ listet schließlich alle Funktionen und Dialoge zum Zuordnen und
Löschen von Benutzern zu bzw. aus Gruppen auf.
1. Funktionsgruppe Benutzerobjekte anlegen, editieren und löschen:
1.1 Funktionen
1.1.1. neuen Informationsraum-Benutzer anlegen
1.1.2. Attribute eines Informationsraum-Benutzers ändern
1.1.3. Informationsraum-Benutzer löschen
Kapitel 3: Requirements Specification
28
1.2. Dialoge
1.2.1. Eingabemaske zum Anlegen eines neuen Informationsraum-Benutzers
anzeigen
1.2.2. Liste aller Informationsraum-Benutzer anzeigen
1.2.3. Attribute eines Informationsraum-Benutzers anzeigen
2. Funktionsgruppe Gruppenobjekte anlegen, editieren und löschen:
2.1. Funktionen
2.1.1. neue Informationsraum-Gruppe anlegen
2.1.2. Attribute einer Informationsraum-Gruppe ändern
2.1.3. Informationsraum-Gruppe löschen
2.2. Dialoge
2.2.1. Eingabemaske zum Anlegen einer neuen Informationsraum-Gruppe
anzeigen
2.2.2. Liste aller Informationsraum-Gruppen anzeigen
2.2.3. Attribute einer Informationsraum-Gruppe anzeigen
3.
Funktionsgruppe Benutzer zu Gruppen zuordnen:
3.1. Funktionen
3.1.1. Benutzer zu Gruppen zuordnen
3.1.2. Benutzer aus Gruppen löschen
3.2. Dialoge
3.2.1. Dialog zum Zuordnen von Benutzern zu Gruppen anzeigen
Wie sich erkennen läßt, sind die Funktionsgruppen „Benutzerobjekte“ und
„Gruppenobjekte“ sehr ähnlich aufgebaut. Durch die Ausnutzung dieser Eigenschaft kann
in der Designphase (siehe Kapitel 5) durch Verallgemeinerung der benötigten Funktionen
der Entwicklungsaufwand verringert werden.
Systemadminsitratoren vs. Projektadministratoren
Projektadministratoren ist es nicht erlaubt, Benutzer einer Systemgruppe zuordnen. Daher
dürfen bei den Dialogen „neuen Informationsraum-Benutzer anlegen“ und „Benutzer zu
Gruppen zuordnen“ die Systemgruppe und alle von der Systemgruppe abgeleiteten
Gruppen nicht als Auswahlmöglichkeit erscheinen. Auch Gruppenobjekte können von
Projektadministratoren nicht der Systemgruppe zugeordnet werden. Daher müssen auch im
Dialog „neue Informationsraum-Gruppe anlegen“ die Systemgruppe und alle abgeleiteten
Gruppen ausgeblendet werden.
Kapitel 3: Requirements Specification
29
Mehrsprachigkeit
Da das Benutzerinterface des Hyperwave Information Server das Anzeigen von Dialogen
in mehreren Sprachen unterstützt, sollen auch die Anzeige der Dialoge zur hierarchischen
Benutzerverwaltung in unterschiedlichen Sprachen möglich sein. Die für die Dialoge der
hierarchischen Benutzerverwaltung vorgesehen Sprachen sind Deutsch und Englisch.
Zuordnen von Benutzern zu mehreren Informationsräumen
Es ist auch denkbar, daß ein Projektadministrator für mehrere Informationsräume
zuständig ist. In diesem Fall wird das Attribut Info_Space mehrfach besetzt.
Löschen von Benutzern aus Informationsräumen
Die Löschfunktion von Projektadministratoren besteht darin, daß nur das entsprechende
Infospace-Attribut aus dem jeweiligen Benutzerobjekt entfernt wird. Damit ist der
entsprechende Benutzer für den Projektadministrator nicht mehr sichtbar. Das
Benutzerobjekt selbst bleibt jedoch bestehen. Die endgültige Entfernung des
Benutzerobjekts können nur Mitglieder der Gruppe System vornehmen.
3.4.2 Nichtfunktionale Systemanforderungen
Nachdem im vorigen Abschnitt die funktionalen Systemeigenschaften an die hierarchische
Benutzerverwaltung beschrieben wurde, erfolgt an dieser Stelle die Aufgliederung der
nichtfunktionalen Systemeigenschaften. Nichtfunktionalen Systemeigenschaften geben
„globale“ Anforderungen an das System wieder, die nicht bestimmten Funktionen oder
Dialogen zugeordnet werden können. [Pfl98] Für die hierarchische Benutzerverwaltung
wurden die folgenden nichtfunktionalen Systemanforderungen festgelegt.
Benutzerfreundlichkeit
Da die Benutzer des Netinfo-Systems bereits mit der Standardoberfläche des Hyperwave
Information Servers vertraut sind, soll auch das Design der Dialoge für die hierarchische
Benutzerverwaltung an das Aussehen und Verhalten der Standardoberfläche angepaßt
werden. Dem Benutzer wird durch das vertraute Erscheinungsbild der Umgang mit den
neuen Funktionen erleichtert. Daneben soll noch folgende Maßnahme getroffen werden,
um die Benutzerfreundlichkeit der hierarchischen Benutzerverwaltung zu erhöhen: Füllt
ein Benutzer ein notwendiges Formularfeld nicht aus, oder ist eine Eingabe nicht zulässig,
so wird der Benutzer durch eine entsprechenden Hinweis auf diesen Umstand aufmerksam
gemacht.
Kapitel 3: Requirements Specification
30
Sicherheit
Es muß gesichert sein, daß es nicht möglich ist, Angaben in der hierarchischen
Benutzerverwaltung durch Verändern der in den Dialogen übermittelten Daten zu
„fälschen“ und so z.B. auf eine höhere Stufe in der hierarchischen Benutzerverwaltung zu
gelangen.
Hohe Benutzeranzahl
Da in diesem System, wie schon erwähnt, eine sehr hohe Anzahl von Benutzern
administriert ist, müssen die Dialoge der hierarchischen Benutzerverwaltung auch
entsprechende Mechanismen bereitstellen, um eine reibungslose Benutzeradmistration
unter diesem Umstand zu ermöglichen.
3.5 Schlußbemerkung
In diesem Kapitel wurde analysiert, welche Funktionalität durch eine hierarchische
Benutzerverwaltung umgesetzt werden soll. Dabei wurde zwischen funktionalen und
nichtfunktionalen Systemeigenschaften unterschieden. Funktionale Systemeigenschaften
beschreiben, wie das System auf bestimmte Eingaben reagieren muß. Nichtfunktionale
Systemeigenschaften beschreiben „globale“ Eigenschaften des Systems, wie
Benutzerfreundlichkeit, Sicherheit oder Performance. Nachdem nun die Anforderungen an
das System „hierarchische Benutzerverwaltung“ untersucht und dokumentiert wurden,
sollen im nächsten Kapitel die Analysephase dieses Projekts mit einer Untersuchung der
Eigenschaften des Hyperwave Information Server fortgesetzt werden, in dessen
Funktionalität das System zur hierarchischen Benutzerverwaltung eingebunden werden
soll.
Kapitel 4
Hyperwave – ein Überblick
Da sich die vorliegende Arbeit mit speziellen Aspekten des Hyperwave Information
Servers12 befaßt, wird in diesem Kapitel die Funktionalität dieses Servers untersucht.
Dabei wird auf wichtige Systemeigenschaften des Servers eingegangen. Vor allem sollen
aber jene Funktionen untersucht werden, die im weiteren Verlauf dieses Projekts zur
Umsetzung einer hierarchischen Benutzerverwaltung ausschlaggebend sein werden.
In diesem Kapitel wird ein kurzer Überblick über die grundlegenden Systemeigenschaften
des Hyperwave Information Servers gegeben. Jene Eigenschaften, die für die praktische
Umsetzung einer hierarchischen Benutzerverwaltung im Gestaltungsbereich
ausschlaggebend sind, werden detailliert behandelt. Die Untersuchung des Hyperwave
Information Servers, mit der sich der Rest dieses Kapitels beschäftigt, beginnt mit einem
kurzen Abriß über dessen Entstehungsgeschichte.
4.1 Was verbirgt sich hinter dem Namen
„Hyperwave“?
Die Ursprünge von Hyperwave finden sich im Jahr 1989 am Institut für
Informationsverarbeitung und Computergestützte neue Medien (IICM) an der TU-Graz. Zu
dieser Zeit wurde am IICM an den Vorgaben für ein "optimal large-scale hypermedia
system" gearbeitet. Dieses System sollte Schwierigkeiten, die bei anderen Systemen zu
dieser Zeit, wie z.B. Videotex, auftraten, beseitigen. Zu diesen Schwierigkeiten zählten
z.B. das Fehlen einer integrierten Suchhilfe, inkonsistente Links, keine klare Trennung
zwischen Inhalt & Layout, u.s.w. Als vom Ministerium für Wissenschaft die Finanzierung
einer Prototyping-Phase zugesagt wurde, begann im Jannuar 1990 die Implementierung
eines Prototyps unter dem Namen Hyper-G. Zwei Programmierer arbeiteten an der ersten
Version des Servers. Der erste Prototyp von Hyper-G implementierte bereits Gopher und
das HTTP-Protokoll.[Mau96]
12
http://www.hyperwave.de
Kapitel 4: Hyperwave – ein Überblick
32
Im Jänner 1992 wurde Hyper-G im universitären Informationssystem der TU Graz
(TUGinfo) zum ersten mal weltweit im praktischen Einsatz erprobt. Der Erfolg dieses
Systems und die steigende Popularität des Internets zeigten, daß Hyper-G tatsächlich für
eine große Anzahl von Anwendungen eingesetzt werden kann. Dieser Erfolg machte es
möglich, eine zweite Phase zu finanzieren, in welcher der Prototyp von Hyper-G in ein
tatsächliches Produkt umgewandelt werden konnte. Diese zweite Phase begann im
Sommer 1992. Seitdem wurde Hyper-G in einer Kooperation aus IICM und dem Institut
für Hypermedia-Systeme des Jonanneum Research weitergeführt. Ein wichtiger
Meilenstein war der Einsatz von Hyper-G bei der European Space Acency (ESA) für ein
"Guide and Directory"-System. [Mau96]
Anfang Februar 1997 gründeten die Entwickler Prof. Dr. Hermann Maurer, Mag. Gerhard
Pail und Dr. Frank Kappe die Hyperwave Information Management GmbH (Hyperwave)
mit Sitz in München. Hyperwave hat sämtliche Rechte sowie den Quell-Code der HyperG-Technologie erworben und wird diese als Hyperwave Information Server (Hyperwave
IS) vermarkten und selbständig weiterentwickeln. Knapp sechs Wochen später wurde
Hyperwave vom amerikanischen Byte Magazine auf der CeBIT in Hannover mit dem
"Best of Show Award" ausgezeichnet. Noch im November desselben Jahres ist die
Hyperwave Information Management GmbH aus München als erstes deutsches
Unternehmen Gewinner des mit 200.000 ECU (2.8 Mio ATS) dotierten "European IT
Prize" der Europäischen Union (EU). Die Firma kann durch zusätzliche Investoren weiter
expandieren und führt 1999 ein Qualitätsmanagement in Übereinstimmung mit dem
Standard ISO 9001 ein. Das Zertifizierungs-Audit konnte innerhalb eines Tages erfolgreich
abgeschlossen werden. Die Entwicklung bei Hyperwave wird durch ein Tool unterstützt,
daß auf dem Hyperwave Information Server basiert. [HDE99]
Nach diesem kurzen Rückblick auf die Entstehungsgeschichte des Hyperwave Information
Servers werden in den weiteren Abschnitten dieses Kapitels die eigentlichen Eigenschaften
des Hyperwave Information Servers untersucht. Kapitel 4.2 bis Kapitel 4.4 beschäftigen
sich mit der Funktionalität des Hyperwave Servers aus der Sicht des Benutzers. Es werden
das Konzept der Hyperwave-Objekte, die Funktionsweise der Benutzerverwaltung und die
Rechtevergabe in Hyperwave beschrieben. Kapitel 4.2 bis Kapitel 4.4 untersuchen den
Hyperwave Server aus der Sicht des Programmierers. Es wird auf die Architektur des
Hyperwave Servers und die Möglichkeiten, die Funktionalität des Hyperwave Servers zu
erweitern, eingegangen.
4.2 Objekte in Hyperwave
Viele Web Server benutzen eine statische, auf Dateien basierende, Architektur von HTMLSeiten, die durch Links miteinander verbunden sind. Hyperwave erzeugt HTML-Seiten
dynamisch. Die auf dem Server abgelegten Daten können vom Benutzer auf verschiedene
Arten, seinen Wünschen entsprechend, betrachtet werden13. Hyperwave speichert
Dokumente in Form von Objekten in einer Art objektorientierten Datenbank. Diese
Objekte beinhalten neben ihren eigentlichen Nutzdaten auch Metadaten in Form von
Attributen. Die Metadaten legen Name, URL, Zugriffsrechte, Dokumenttyp, Autor, usw.
13
"One Document- Multiple Views"
Kapitel 4: Hyperwave – ein Überblick
33
des entsprechenden Objekts fest. [HwU98] Abbildung 4.1 zeigt die Attribute eines HTMLDokuments, wie sie durch das Benutzerinterface des Hyperwave Information Servers
dargestellt werden.
Abbildung 4.1: Attribute eines HTML-Dokuments auf einem Hyperwave Server
Die wichtigsten in Hyperwave definierten Attribute sind: [DH96]

GOid: Globale Objekt ID - Diese eindeutige ID setzt sich aus der IP-Adresse des
Servers und einer laufenden Nummer zusammen.

Name (URL): URL des Objekts - Über den Unified Resource Locator kann das Objekt
über das HTTP-Protokoll angesprochen werden. In diesem Fall wird es zur Darstellung
in einem Browser dynamisch in eine vom Server erzeugte HTML-Seite eingebettet.

Title: Titel des Objekts - Jedes Objekt kann neben seinem Namen (URL) auch einen
oder mehrere Titel besitzen. Titel können mehrsprachig angegeben werden.
Kapitel 4: Hyperwave – ein Überblick
34

Rights: Rechtevergabe - Für jedes Objekt können Zugriffsrechte für Lesen,
Modifizieren und Löschen vergeben werden. Nur Benutzer, die für das Objekt
entsprechende Rechte haben, dürfen auf die entsprechende Art darauf zugreifen.

MimeType: Dokumentart - Durch den MimeType wird der Inhalt des Objekts näher
bestimmt. So können beliebige Dokumentarten wie z.B. Word-Dokumente, Bilder,
Sound-Dateien, usw. auf dem Hyperwave Information Server gespeichert werden.
Neben Objekten, die Inhalte jeglicher Art darstellen können, existiert noch eine zweite
große Gruppe von Objekten in Hyperwave, die sogenannten Containerobjekte.
Containerobjekte haben keinen eigentlichen Inhalt, sondern stellen vielmehr Strukturen zur
Verfügung, die weitere beliebige Objekt aufnehmen können. Das einfachste
Containerobjekt in Hyperwave ist die Collection. Collections können beliebige Objekten
aufnehmen. Collections erlauben es in Hyperwave hierarchische Strukturen von
Collections und Dokumenten anzulegen, ähnlich wie Verzeichnishierarchien in
Filesystemen angelegt werden können. Abbildung 4.2 zeigt den prinzipiellen Aufbau einer
Collection. Zwischen der Collection und den darin befindlichen Objekten existieren
Verknüpfungen, die den Zugriff auf das Containerobject bzw. auf die darin befindlichen
Objekte ermöglichen. Diese Verknüpfungen werden vom Server beim Einfügen eines
Dokuments in eine Collection automatisch generiert. [HwU98]
Collection
Abbildung 4.2: Collections sind Contianerobjekte für beliebige Objekte.
Eine weiteres Containerobjekt ist die Sequence. Sequences ermöglichen es für die in ihnen
beinhaltete Objekte eine Reihenfolge festzulegen. Der Benutzer kann durch die
beinhalteten Objekte in einer vordefinierten Reihenfolge navigieren. Eine Sequence ist also
eine "geordnete Collection". Abbildung 4.3 zeigt das schematische Bild einer Sequence.
Neben Verknüpfungen zwischen dem Container selbst und den darin befindlichen
Objekten generiert der Server beim Einfügen eines Dokuments in eine Sequence auch
Verknüpfungen zwischen diesen Objekten. Dadurch wird eine Reihenfolge auf die Objekte
in einer Sequence definiert. [HwU98]
Kapitel 4: Hyperwave – ein Überblick
35
Sequence
Abbildung 4.3: Eine Sequence definiert einer Reihenfolge auf ihren Inhalt.
Neben Sequences und Collections existieren in Hyperwave noch zwei weitere Arten von
Containerobjekten. Diese besitzen die Bezeichnungen Multicluster und Alternativcluster.
Während Collections und Sequences eine Liste der beinhalteten Objekte darstellen,
kombiniert ein Multicluster alle beinhalteten Objekte und stellt das Ergebnis dar. Dieser
Vorgang erfolgt dynamisch unter Berücksichtigung der Einstellungen und Attribute des
momentanen Benutzers. Ein Alternativcluster stellt im Gegensatz zum Multicluster nicht
die Kombination aller beinhalteten Objekte dar, sondern wählt ein Objekt zur Darstellung
aus. Die Auswahl des dargestellten Objekts wird ebenfalls anhand der Einstellungen und
Attribute des momentanen Benutzers getroffen. [HwU98]
Um dem Hyperwave Information Server diese Auswahl zu ermöglichen, muß dem Server
bekannt sein, welcher Benutzer auf das betroffene Cluster-Objekt zugreifen möchte. Dies
wird dem Server durch die integrierte Benutzerverwaltung ermöglicht. Benutzer können
entweder anonym, d.h. ohne Identifizierung am Server arbeiten, oder sich durch LoginKennung und Passwort identifizieren. Anhand einer erfolgreichen Identifizierung kann der
Server die Darstellung des ausgewählten Objekts ändern. Ist z.B. ein Benutzer mit
Systemrechten am Server identifiziert, so ändert der Server die Darstellung des
ausgewählten Objekts so, daß dieses vom Benutzer auch editiert werden kann. Nachdem in
diesem Kapitel auf das auf Objekten basierende Konzept eingegangen wurde, durch das
der Hyperwave Information Server Dokumente in seiner Datenbank ablegt, wird im
folgenden Kapitel die oben angesprochene Benutzerverwaltung des Hyperwave
Information Servers genauer untersucht.
4.3 Benutzerverwaltung
Neben der Möglichkeit als anonymer Benutzer auf einen Hyperwave Information Server
zuzugreifen, bietet Hyperwave die Möglichkeit sich am Server zu identifizieren. Nach
erfolgter Anmeldung durch einen eindeutigen Benutzernamen und ein dazugehöriges
Paßwort kann der Benutzer den vollen Funktionsumfang des Hyperwave Information
Servers nutzen. Zu diesen Funktionen zählt unter anderem das Editieren von Objekten, auf
die der identifizierte Benutzer auf Grund seiner Rechte Zugriff hat. Dadurch wird
Hyperwave zu einem Multi-User-System, in dem die Dokumente des einen Benutzers vor
Zugriffen anderer Benutzer geschützt werden können. Benutzerdaten werden ebenfalls in
Form von Objekten in der Datenbank des Hyperwave-Servers abgelegt. Abbildung 4.4
zeigt die Attribute eines Benutzerobjekts.
Kapitel 4: Hyperwave – ein Überblick
36
Die wichtigsten Attribute eines Benutzerobjekts sind: [DH96]

Uname: Benutzername - Eindeutige Login-Kennung des Benutzers

Passwd: Paßwort - Paßwort des Benutzers14

Group: Gruppen - Gruppen, denen Benutzer angehört
Neben Benutzerobjekten können auch Gruppenobjekte in Hyperwave angelegt werden.
Einzelne Benutzer können diesen Gruppen zugeordnet werden. Dadurch wird die
Benutzerverwaltung erheblich erleichtert, da, wie sich in Kapitel 4.4 zeigen wird,
Zugriffsrechte auch für ganze Gruppen vergeben werden können. Die Benutzerverwaltung
kann ausschließlich von der Gruppe der Systemadministratoren vorgenommen werden. Ein
Benutzer wird zu einem Systemadministrator, indem er in die vordefinierte Gruppe
system oder eine davon abgeleitete Gruppe aufgenommen wird. [DH96]
Abbildung 4.4:Benutzerdaten werden von Hyperwave ebenfalls als Objekte behandelt.
14
Das Paßwort wird in verschlüsselter Form in den Attributen des Benutzers abgelegt.
Kapitel 4: Hyperwave – ein Überblick
37
Nachdem die Benutzerdaten am Server vorliegen, können für jedes Objekt sogenannte
Zugriffsrechte definiert werden. Durch die Vergabe von Zugriffsrechten wird festgelegt,
welche Benutzer in welchem Modus15 auf das entsprechende Objekt zugreifen darf. Da die
Vergabe von Zugriffsrechten eine wichtige Eigenschaft de Hyperwave Information Servers
ist, die auch für die Umsetzung einer hierarchischen Benutzerverwaltung von großer
Wichtigkeit sein wird, soll diese im Folgenden genauer untersucht werden.
4.4 Rechtevergabe
Wie in Kapitel 4.3 bereits erwähnt wurde, können für jedes Objekt16 Zugriffsrechte
vergeben werden. Durch die Vergabe von Zugriffsrechten wird definiert, welchem
Benutzer welche Art des Zugriffs auf das Objekt gestattet ist. Mit Hilfe der Zugriffsrechte
kann eine Multiple-Authoring Umgebung geschaffen werden, in der die Objekte des einen
Benutzers vor Zugriffen anderer Benutzer geschützt sind. Es werden drei Arten von
Rechten unterschieden: [Mau96]

Read: Lesen - Benutzer, die nur Leserechte auf ein Objekt besitzen, dürfen dieses
Objekt zwar lesen aber nicht editieren oder löschen.

Write: Editieren und Löschen - Benutzer, die das Schreibrecht auf ein Objekt besitzen,
dürfen dieses lesen, editieren und löschen.

Unlink: Aus Containerobjekten Löschen - Das Unlink-Recht kommt nur bei
Containerobjekten17 zum Einsatz. Benutzer, die das Unlink-Recht besitzen dürfen in
dem entsprechenden Containerobjekt Objekte verschieben und löschen.
Die Zugriffsrechte auf ein Objekt werden im Attribut „Rights“ des entsprechenden Objekts
in Form eines „Rechtestrings“ festgehalten. Der voreingestellte Wert ist der leere
Rechtestring. Der leere Rechtestring entspricht der Bedeutung, daß alle Benutzer
Leserechte, aber nur Systemadministratoren18 und der Autor des Objektes Schreib- und
Unlinkrechte für das betroffene Objekt besitzen. Durch die Vergabe eines Rechtestrings
können die Leserechte auf ein Objekt eingeschränkt, Schreib- und Unlinkrechte erweitert
werden. [Mau96] Das Format eines gültigen Rechtestrings ist folgendermaßen aufgebaut:
Die drei Arten der möglichen Benutzerrechte read, write, und unlink werden durch
entsprechende Großbuchstaben im Rechtestring abgekürzt. Dabei steht der Buchstabe R
für read, der Buchstabe W für write und der Buchstabe U für unlink. Diese drei Arten von
Benutzerrechten können für den Autor eines Objekts, für einzelne Benutzer oder für ganze
Gruppen von Benutzern vergeben werden. Um Rechte für den Autor eines Objekts
festzulegen, muß der Kleinbuchstabe a für Autor im Rechtestring angegeben werden.
Rechte für einzelne Benutzer werden durch ein kleines u, gefolgt von einer Liste der
15
Die drei möglichen Zugriffsmodi auf Objekte sind Lesen, Schreiben und Löschen.
16
Benutzer- und Gruppenobjekte sind davon ausgenommen.
17
z.B. collection, cluster. Siehe auch Kapitel 4.2.
18
Gruppenmitglieder der vordefinierten Gruppe system.
Kapitel 4: Hyperwave – ein Überblick
38
entsprechenden Benutzern festgelegt. Um Rechte für ganze Gruppen anzugeben muß
schließlich der Buchstabe g, gefolgt von einer Liste der gewünschten Gruppen im
Rechtestring angegeben werden. [Mau96] Die drei folgenden Beispiele sollen die Vergabe
von Rechtestrings erläutern. Diese Beispiele orientieren sich an [Mau96].
Rights: W:g ni_write
Beispiel 4.1: Die Gruppe ni_write besitzt Schreibrechte.
Wird der Rechtestring aus Beispiel 4.1 im Rights-Attribut eines Objektes angegeben, so
besitzen alle Benutzer Leserechte für das entsprechende Objekt. Diese Einstellung wird
von den default-Werten des leeren Rechtestrings übernommen: Werden keine Leserechte
angegeben, so dürfen alle Benutzer das entsprechende Objekt lesen. Außerdem haben auf
Grund der im Rechtesstring angegebenen Schreibrechte neben dem Autor des Objekts und
der Gruppe system auch die Gruppe mit dem Namen ni_write Schreibrechte auf das
Objekt.
Rights: R:a u hschwarz
Beispiel 4.2: Nur der Autor und der Benutzer hschwarz besitzen Leserechte.
Der Rechtestring aus Beispiel 4.2 bedeutet, daß nur dem Autor dieses Objekts und dem
Benutzer mit der Login-Kennung hschwarz lesender Zugriff auf das Objekt gestattet ist.
Systembenutzer haben weiterhin uneingeschränkten Zugriff auf dieses Objekt.
Rights: W:g test1 test2; U:g test2
Beispiel 4.3: Die Gruppe test2 darf Objekte aus Contaionerobjekten löschen.
Der in Beispiel 4.3 angeführte Rechtestring bedeutet, daß Benutzer, die den Gruppen
test1 und test2 angehören, das entsprechende Objekt lesen, editieren und löschen
dürfen. Handelt es sich dabei um ein Containerobjekt, so dürfen Mitglieder der Gruppen
test1 und test2 Objekte in das Containerobjekt einfügen, jedoch nur Benutzer, die der
Gruppe test2 angehören, dürfen Objeke aus dem Containerobjekt wieder entfernen
(Unlink-Rechte). Handelt es sich um kein Containerobjekt, so werden die Unlink-Rechte
ignoriert.
In den letzten drei Abschnitten wurden die Eigenschaften des Hyperwave Information
Servers aus der Sicht des Benutzers betrachtet. In Kapitel 4.2 wurde untersucht, wie
Dokumente am Hyperwave Information Server abgelegt werden. Dabei wurde festgestellt,
daß der Hyperwave Information Server Dokumente in einer Art objektorientierter
Datenbank ablegt. Jedem Dokument werden dabei Metainformationen zugewiesen, die in
Attributen gespeichert werden und die Eigenschaften des entsprechenden Dokuments
beschreiben. Kapitel 4.3 beschäftigte sich mit der Benutzerverwaltung, die von Hyperwave
unterstützt wird. Es können Benutzer- und Gruppenobjekte erzeugt werden. Benutzer
können sich am System identifizieren und dadurch den vollen Funktionsumfang des
Hyperwave Information Servers nutzen. In Kapitel 4.4 wurde die Vergabe von Rechten
näher untersucht. Durch die Vergabe eines Rechte-Attributes kann festgelegt werden,
Kapitel 4: Hyperwave – ein Überblick
39
welche Benutzer und Benutzergruppen Zugriffsrechte auf ein bestimmtes Objekt haben.
Dabei wurde zwischen read-, write- und unlink-Rechten unterschieden.
Die weiteren Abschnitte des Kapitel 4 „ Hyperwave – ein Überblick“ beschäftigen sich mit
den Eigenschaften des Hyperwave Information Servers aus der Sicht des Programmierers.
Dabei wird vor allem auf die Programmiermöglichkeiten des Hyperwave Information
Servers eingegangen. Bevor diese Möglichkeiten näher untersucht werden, folgt im
nächsten Abschnitt ein kurzer Überblick über den internen Aufbau des Hyperwave
Information Servers.
4.5 Architektur des Hyperwave-Servers
Der Hyperwave Information Server besteht nicht aus einem einzigen großen Block von
Software, sondern vielmehr aus einer Gruppe von unabhängigen Modulen, die über
definierte Schnittstellen zusammenarbeiten. [HwA98]
Clients
Hyperwave
HG-CSP
418
WWW
Gopher
HTTP
Net Mgr.
Gopher
80
wavemaster
SNMP
70
161
gophgate
snmpagent
418
HG-CSP
dbserver
Session
layer
to remote
servers
hgserver
ftserver
Protocol
conversion
layer
dcserver
Database
layer
to remote
servers
Full text Index
Objects
Local
Docs
Cached
Docs
Abbildung 4.5: Die Architektur des Hyperwave Information Servers
Abbildung 4.5 zeigt die Module des Hyperwave Information Servers. Im Wesentlichen
besteht der Hyperwave Information Server aus drei verschiedenen Layers: Dem ProtocollConversion-Layer, dem Session-Layer und dem Database-Layer. Der ProtocollConversion-Layer macht die darunterliegenden Schichten protokollunabhängig. Ein
Kapitel 4: Hyperwave – ein Überblick
40
wichtiges Modul, das zum Protocoll-Conversion-Layer gehört, ist der Wavemaster (siehe
auch Kapitel 4.6). Der Wavemaster übersetzt das aus dem WWW bekannte HTTPProtokoll in das Hyperwave interne Client-Server Protokoll (HG-CSP), so daß
darunterliegende Schichten nur mehr mit diesem Protokoll zu tun haben. [HwA98]
Der Session-Layer kommuniziert mit dem Database-Layer. Für jede Client-Verbindung
wird eine eigene Instanz des Session-Layers erzeugt. Der Session-Layer ist dafür
verantwortlich, das zustandslose HTTP-Protokoll in das Session-orientierte, interne ClientServer Protokoll (HG-CSP) zu übersetzen. Der Session-Layer handelt zu Beginn einer
Session mit dem Web Client Übertragungsparameter aus, die während der gesamten
Dauer, die der Web-Client mit dem Hyperwave Information Server kommuniziert,
beibehalten werden. [HwA98]
Im Database-Layer werden die eigentlichen Dokumente, Links und Metainformationen
gespeichert. Der Database-Layer besteht aus den Modulen Object-Server, Fulltext-Server
und Document-Server. Der Objekt Server19, erzeugt Objekte und deren Beziehungen
untereinander, modifiziert und löscht Objekte, indiziert Objekte für die Suche und
verwaltet die Zugriffskontrolle. Der Fulltext-Server, beinhaltet einen invertierten Index
aller Dokumente für die Suche. Die dritte Komponente ist der Document-Server, der lokale
Dokumente und häufig verwendete Dokumente von Remote-Servern zwischenspeichert.
[HwA98]
Nachdem in diesem Kapitel kurz auf den internen Aufbau des Hyperwave Information
Servers eingegangen wurde, soll im nächsten Kapitel das zum Protocoll-Conversion-Layer
gehörende Wavemaster-Modul näher untersucht werden. Der Wavemaster stellt das "Front
End" des Hyperwave Information Servers dar. Der Wavemaster definiert die optische
Darstellung für den Benutzer. Änderungen der Funktionalität des Hyperwave Information
Servers können durch Programmierung des Wavemaster-Moduls bewirkt werden.
[HwA98]
4.6 Der Wavemaster
Wie bereits in Kapitel 4.5 erwähnt wurde, besteht die Aufgabe des Wavemaster-Moduls
darin, das HTTP-Protokoll in das interne HG-CSP zu übersetzten. Wird von einem WebClient ein HTTP-Requests an den Hyperwave Information Server gesendet, so wird dieser
Request vom Wavemaster in das interne HG-CSP übersetzt und an den Session-Layer
weitergeleitet. Der Session-Layer führt den HG-CSP Request aus und sendet das Ergebnis
an den Wavemaster zurück. Der Wavemasters übersetzt das Ergebnis des HG-CSP
Requests in eine HTML-Seite und sendet diese als Antwort auf den ursprünglichen HTTPRequest an den Client zurück. Der Wavemaster ist somit für die optische Darstellung von
Inhalten am Server verantwortlich. Die optische Darstellung wird durch den Wavemaster
vom tatsächlichen Inhalt des Hyperwave Information Server getrennt. Die am Server
abgelegten Daten werden unabhängig von ihrer Darstellung gespeichert. Erst der
Wavemaster verleiht diesen Daten ein optisches Erscheinungsbild. Dadurch ist es z.B.
möglich auf die Daten eines Hyperwave Servers über zwei verschiedene WavemasterModule zuzugreifen, welche den dargestellten Daten zwei völlig verschiedene
19
Als Datenbank kann entweder Wavestore oder Oracle eingesetzt werden.
Kapitel 4: Hyperwave – ein Überblick
41
Erscheinungsbilder geben. Durch den Wavemaster wird das „Look&Feel“ vom Inhalt
getrennt. [HwA98]
Abbildung 4.6 zeigt, wie eine Collection-Listing, das durch einen Web Client betrachtet
wird, dargestellt wird. Das Collection-Listing selbst, das Benutzerinterface und die
Elemente für die Navigation werden vom Wavemaster in eine einzelne, dynamisch
generierte HTML-Seite übersetzt, die dann vom Web Client visualisiert wird. [HwA98]
Abbildung 4.6: Ansicht eines Collection-Listings, wie es vom Wavemaster dargestellt
wird.
Das Aussehen der dynamisch generierten HTML-Seite wird durch einen Satz von Dateien
bestimmt, die am Server abgelegt sind. Diese Dateien werden als Wavemaster-Templates
bezeichnet und befinden sich in einem eigenen Verzeichnis20. Diese können vom
Programmierer beliebig verändert werden, um dadurch die Darstellung der vom
Wavemaster dynamisch generierten HTML-Seiten zu gestalten. Der Programmierer hat
20
Die Wavemaster-Templates befindet sich üblicherweise im Verzeichnis „wavemaster“
Kapitel 4: Hyperwave – ein Überblick
42
folgende Möglichkeiten, um in die Wavemaster-Templates eingreifen zu können:
[HwA98]

PLACE: PLACE ist eine eigene, für die Programmierung der Wavemaster-Templates
entwickelte Programmiersprache. Durch die Abfrage bestimmter PLACE-Variablen,
die Auskunft über den momentanen Status des Servers geben, kann auf Aktionen des
Benutzers reagiert werden. [HwA98] Die Programmiersprache PLACE wird in Kapitel
4.7 besprochen.

SSJS: ServerSide JavaScript - Der Hyperwave Information Server unterstützt auch das
Einbinden von serverseitigem JavaScript in die Wavemaster-Templates. Mithilfe von
SSJS21 können Aktionen ausgeführt werden, die mit der relativ einfachen Sprache
PLACE nicht möglich sind. Die Schnittstelle zwischen dem Server und SSJS bildet
eine eigene HW_API-Schnittstelle, die es SSJS erlaubt, direkt auf Objekte am Server
zuzugreifen. [HwA98] Auf SSJS unter Hyperwave wird in Kapitel 4.8 näher
eingegangen.
Auch für die Umsetzung einer hierarchischen Benutzerverwaltung wird in die
Programmierung der Wavemaster-Templates eingeriffen werden, um damit die
notwendigen Änderungen im Benutzerinterface des Hyperwave Information Servers
bewirken zu können.
4.7 PLACE
PLACE ist eine Meta-HTML-Sprache, mit deren Hilfe das Benutzerinterface und die
Funktionsweise des Hyperwave Information Servers verändert und erweitert werden
können. Der Name PLACE kommt von den sogenannten Placeholders, die in PLACE
benutzt werden. Die Placeholders übertragen Informationen über das aktuelle Objekt, den
Benutzerstatus, usw. zwischen dem Wavemaster und dem darunterliegenden Layer. Die
Programmiersprache PLACE besteht aus den Sprachkonstrukten if-Statement, whileSchleife und macro-Aufruf. [HwP98] PLACE kommt in den Wavemaster-Templates (siehe
Kapitel 4.6) zum Einsatz, die eine Mischung aus PLACE-Anweisungen und HTML-Code
enthalten. Ein solches Template kann z.B. feststellen, ob am Server ein Fehler augetreten
ist und in diesem Fall eine entsprechende Fehlermeldung anzeigen, den aktuellen Benutzer
anzeigen, die Parents einer Collection auflisten, einen Dialog zum Anlegen eines neuen
Benutzers anzeigen, usw. PLACE-Anweisungen beginnen und enden jeweils mit einem
doppelten %-Zeichen. [HwP98] Im Folgenden werden die Eigenschaften der Sprache
PLACE anhand einiger Beispiele untersucht.
%%if action == action.identify%%
Der Benutzer hat die Aktion action.identify aufgerufen.
21
ServerSide JavaScript
Kapitel 4: Hyperwave – ein Überblick
43
%%endif%%
Beispiel 4.4: Eine einfache if-Anweisung in PLACE.
Beispiel 4.4 zeigt den Syntax einer einfachen if-Anweisung in PLACE. If-Anweisungen
werden in PLACE immer mit %%endif%% abgeschlossen. Außerdem zeigt dieses Beispiel
das unter Hyperwave verwendete Konzept der „action“. Actions werden verwendet, um
dem Server mitzuteilen, welche Aktion vom Benutzer am Client aufgerufen wurde. Wählt
der Benutzer z.B. den Menüpunkt „Identifizieren“, um sich am System anzumelden, so
wird ein Request zum Server abgeschickt, in dessen URL die vom Benutzer gewählte
Aktion in codierter Form übertragen wird. Der Server reagiert auf die mitgeschickte
Aktion und sendet eine entsprechende dynamisch generierte HTML-Seite an den Client
zurück. In PLACE kann über den Platzhalter action der Namen der vom Benutzer
aufgerufenen Aktion ausgelesen werden. Die if-Anweisung in diesem Beispiel wird daher
nur ausgeführt, falls der Benutzer zuvor die Aktion action.identify aufgerufen hat. In
diesem Fall wird der Text in Zeile 2 dieses Beispiels dynamisch in die generierte HTMLSeite eingebunden.
%%if session.language==”ge”%%
Notizen
%%else%%
Annotations
%%endif%%
Beispiel 4.5: Ein if-Anweisung mit else-Zweig.
Beispiel 4.5 zeigt ein PLACE-Anweisung, um, abhängig von der vom Benutzer
eingestellten Sprache, Text in die generierte HTML-Datei einzubinden. Der Platzhalter
session.language liefert die vom Benutzer am Client ausgewählte Sprache als Ergebnis
zurück. Liefert die if-Anweisung in diesem Beispiel false als Ergebnis zurück, so wird
der else-Zweig der Anweisung in Zeile 4 ausgeführt.
%%macro sample_macro%%
<TABLE>
<TR>
<TD>%%ge: Notizen, :Annotations%%</TD>
</TR>
%%while annotations.next_entry%%
<TR>
<TD>%%annotations.entry.title%%</TD>
</TR>
%%endwhile%%
</TABLE>
%%endmacro%%
Beispiel 4.6: PLACE erlaubt auch die definition von Makros.
Beispiel 4.6 zeigt eine Macrodefinition in PLACE. Ein Macro beginnt mit der PLACEAnweisung %%macro <macroname>%% und endet mit der Anweisung %%endmacro%%.
Wird ein Macro aufgerufen, so wird der Code zwischen diesen beiden Anweisungen
ausgeführt. Das Macro in diesem Beispiel gibt eine Tabelle aus, die alle Notizen, die zum
Kapitel 4: Hyperwave – ein Überblick
44
aktuellen Objekt existieren, auflistet. Dazu wird in Zeile vier, abhängig von der vom
Benutzer eingestellten Sprache, „Notizen“ oder „Annotations“ ausgegeben. Die in Zeile 4
verwendete PLACE-Anweisung ist eine Kurzschreibweise für die in Beispiel 4.5
verwednete PLACE-Anweisung. Danach werden in einer while-Schleife alle zum aktuellen
Objekt existierenden Notizen durchlaufen und deren Titel ausgegeben. Der Platzhalter
annotations.next_entry liefert als Ergebnis true zurück, solange weitere Notizen
zum aktuellen Objekt existieren und setzt den Notiz-Zähler automatisch auf die nächste
Notiz. Der Platzhalter annotations.entry.title gibt den Inhalt des Title-Attributes
jener Notiz in der vom Benutzer eingestellten Sprache aus, auf die der Notiz-Zähler
momentan zeigt. Eine vollständige Liste aller unter PLACE definierten Platzhalter findet
man in [PLA99].
Wie man an diesen Beispielen bereits erkennen kann, sind die Möglichkeiten, die PLACE
bietet, um in die Programmierung der Wavemaster-Templates einzugreifen, sehr
beschränkt. Es gibt in PLACE keine Möglichkeit benutzerdefinierte Variablen zu
erzeugen. Ein weiteres Einschränkung von PLACE ist, daß nur Informationen ausgelesen
werden können, die das aktuelle Objekt betreffen. Außerdem können diese Informationen
nicht geändert werden. Daher ist es mit PLACE z.B. nicht möglich die Attribute eines
Objekts tatsächlich zu ändern. Um so komplexe Aufgaben ausführen zu können, muß auf
Serverside JavaScript, das ebenfalls zur Programmierung der Wavemaster-Templates
eingesetzt werden kann, zurückgegriffen werden. Im folgenden Abschnitt wird daher die
Programmierung des Hyperwave Information Servers mittels JavaScript genauer
untersucht.
4.8 JavaScript in Hyperwave
JavaScript ist eine eine einfache, interpretierte Programmierprache mit rudimentären
objektorientierten Eigenschaften. JavaScript kann zur Programmierung im WWW in zwei
völlig unterschiedlichen aber sich überschneidenden Bereichen eingesetzt werden.
Clientside JavaScript läuft auf Web-Browsern, Serverside JavaScript läuft auf WebServern. JavaScript orientiert sich an den Programmiersprachen C, C++ und Java und ist
eine typenlose Sprache, d.h. Variablen in JavaScript müssen keinen bestimmten Typ
besitzen. Objekte in JavaScript können eher mit Assoziativen Arrays in Perl als mit
tatsächlichen Objekten in C++ oder Java verglichen werden. Die Programmiersprache
JavaScript wurde von Netscape Communications Cooperations für die Verwendung im
Navigator Web-Browser (clientside JavaScript) und in Netscape‘s Server-Produkten
(serverside JavaScript) entwickelt. [Fla98] Hyperwave hat JavaScript als Programmiersprache für den Hyperwave Information Server übernommen und unterstützt zwei
Möglichkeiten, um JavaScript in die Programmierung des Servers einfließen zu lassen:
[HwP98]

HWJS: HWJS ist ein Commandline-Tool, das JavaScript Files interpretieren kann. Mit
diesem Werkzeug ist es möglich, auf den Hyperwave Information Server mittels einer
Script-Sprache zuzugreifen. In HWJS sind eine Menge von JavaScript-Objekten
vordefiniert, die es ermöglichen auf den Server zuzugreifen und dort Operationen
vorzunehmen. HWJS bietet somit eine komfortable Möglichkeit, um CGI-Programme
zu erstellen. [HwP98]
Kapitel 4: Hyperwave – ein Überblick

45
JavaScript in den Wavemaster Templates: Eine weitere Möglichkeit, um JavaScript
in die Programmierung des Hyperwave Information Servers einfliessen zu lassen ist
JavaScript in die Wavemaster-Templates einzubetten (siehe Kapitel 4.6). JavaScript
kann in den Templates verwendet werden, um Operationen durchzuführen, welche die
Möglichkeiten von PLACE bei weitem übersteigen. [HwP98]
Nachdem an dieser Stelle die beiden Möglichkeiten, um JavaScript in die Programmierung
des Hyperwave Information Servers einfließen zu lassen kurz aufgezeigt wurden, sollen
diese beiden Möglichkeiten in den nächsten beiden Abschnitten genauer untersucht
werden.
4.8.1 HWJS
Wie bereits in der Einleitung dieses Kapitels erwähnt wurde, ist hwjs ein Werkzeug mit
dem mittels JavaScript auf den Hyperwave Information Server zugegriffen werden kann.
hwjs-Scripts enthalten reinen JavaScript-Code, der von dem Commandline-Tool hwjs
interpretiert wird. Die Funktionsweise von hwjs soll am Beispiel eines kurzen hwjs Scripts erklärt werden:
// das ist die Datei hello.js
writeln(“hello world”);
Beispiel 4.7: Das auszuführende Script wird unter dem Namen hello.js gespeichert.
Die Datei, die das hwjs -Script enthält, trägt den Namen hello.js und enthält das in
Beispiel 4.7 angeführte Script. Um dieses hwjs-Script zu starten, muß das Komando aus
Beispiel 4.8 ausgeführt werden.
hwjs hello.js
// gibt hello world am Terminal aus
Beispiel 4.8: Wird dieses Komando am Terminial eingegeben, so wird der JavaScript-Code
in der Datei hello.js ausgeführt.
Es ist auch möglich hwjs über den System Loader zu starten. Um das zu erreichen, muß
am Beginn des Scripts die in Beispiel 4.9 angeführte Zeile in das Testprogramm eingefügt
werden.
#!/usr/local/bin/hwjs
// das ist das Testprogramm
writeln(“hello world”);
Beispiel 4.9: Scripts können auch über den System Loader gestartet werden.
Nun kann das Script auch gestartet werden, ohne explizit hwjs aufzurufen. In diesem Fall
muß, wie Beispiel 4.10 zeigt, nur mehr der Name der auzuführenden Script-Datei
angegeben werden.
Kapitel 4: Hyperwave – ein Überblick
46
hello.js
// prints hello world on the terminal
Beispiel 4.10: Nachdem das Komando für den System Loader angegeben wurde, muß am
Terminal nur mehr der Name der auszuführenden Datei angegeben werden.
hwjs unterstützt eine Menge vordefinierter Objekte, um den Zugriff auf den Hyperwave
Information Server zu ermöglichen. Tabelle 4.1 wurde [HwP98] entnommen und zeigt eine
Liste aller in hwjs definierten Objekte. Eine genaue Erklärung der Funktionsweise dieser
Objekte findet man in [HwP98].
Class/Object
Description
HW_API_Attribute
attribute
HW_API_Object
object
HW_API_ObjectArray
objectarray
HW_API_Reason
reason for error reporting
HW_API_Error
error
HW_API_Content
content representation
HW_API_Server
the communication class
KeyValue
key value pairs for http header
KeyValueField
field of keyvalue
HTMLJavaScriptParser
HTML parser
SendMail
mail facility
File
file access facility
OptionParser
Command line parsing tool
argv
the command line object
environment
Environment variables
write()
writes into the output document
writeln()
writes into the output document
writeError()
writes on stderr (debug only)
read()
reads from stdin
readln()
reads a line from stdin
Kapitel 4: Hyperwave – ein Überblick
47
getpass()
reads hidden information (password) from the stty
interactive()
true when hwjs was executed in the command line
exit()
exits the program
include()
includes a file
system()
executes a command line in the shell
sleep()
pauses the program for a number of seconds
crypt()
encrypts a string
escape()
encodes a URL
unescape()
unencodes a URL
Tabelle 4.1: Vordefinierte Objekte in HWJS
Die mit der Bezeichnung HW_API beginnenden Objekte unterstützen den direkten Zugriff
auf den Server, um Objekte lesen, modifizieren und löschen zu können. Diese Objekte
können auch in den Wavemaster-Templates eingesetzt werden, um auf den Server
zuzugreifen (siehe auch Kapitel 4.8.2). Ein kurzes Beispiel für den Zugriff auf ein
Hyperwave-Objekt mit JavaScript folgt am Ende von Kapitel 4.8.2.
4.8.2 JavaScript in den Wavemaster-Templates
JavaScript kann in den Wavemaster-Templates verwendet werden, um Operationen
durchzuführen, welche die Möglichkeiten von PLACE bei weitem übersteigen. JavaScript
kann folgendermaßen in die Wavemaster-Templates eingebunden werden: [HwP98]

JavaScript wird von dem <SERVER> und dem </SERVER> Tag eingeschlossen.

JavaScript befindet sich in einem eigenen File und wird mit dem include-Tag
eingebunden. <SERVER SRC = "file://path/filename">

JavaScript wird in einem HTML-Tag als Attribut-Name durch Backquotes
eingebunden.

JavaScript wird in einem HTML-Tag als Attribut-Wert durch Backquotes eingebunden.
Beispiel 4.11 wurde [Hwp98] entnommen und zeigt die oben erklärten Möglichkeiten, um
JavaScript in die Wavemaster-Templates einzubinden.
<!-- this is a HTML template -->
<H1>Welcome</H1>
<SERVER>
// this is pure JavaScript
Kapitel 4: Hyperwave – ein Überblick
48
function pref()
{
return “HREF”;
}
function url()
{
return “http://hyperwave.com”;
}
write(“hello and welcome”);
</SERVER>
<!—- invocation in a tag -->
<A ‘pref()‘=‘url()‘>Go to Hyperwave</A>
<!—- a include -->
<SERVER SRC=”file://test.js”>
Beispiel 4.11: Hyperwave unterstützt mehrere Möglichkeiten, um SSJS in die
Wavemaster-Templates einzubinden.
Auch über JavaScript in den Wavemaster-Templates ist es möglich auf eine Vielzahl
vordefinierter JavaScript Objekte zurückzugreifen, um Manipulationen von Objekten am
Server vornehmen zu können. Tabelle 4.2 wurde [HwP98] entnommen und zeigt eine
Zusammenfassung aller in den Wavemaster-Templates vordefinierten Objekte. Eine
genaue Erklärung der Funktionsweise dieser Objekte kann in [HwP98] gefunden werden.
Class/Object
Description
HW_API_Attribute
attribute
HW_API_Object
object
HW_API_ObjectArray
objectarray
HW_API_Reason
reason for error reporting
HW_API_Error
error
HW_API_Content
content representation
HW_API_Server
the communication class
KeyValue
key value pairs for http header
KeyValueField
field of keyvalue
HTMLJavaScriptParser
HTML parser
SendMail
mail facility
File
file access facility
server
the current server object
Kapitel 4: Hyperwave – ein Überblick
49
request
the current request object
response
the current response object
wavemaster
wavemaster information object
client
the client object
write()
writes into the document
writeln()
writes into the document
writeError()
writes on stderr (debug only)
crypt()
encrypts a string
escape()
encodes a URL
unescape()
unencodes a URL
Tabelle 4.2: Vordefinierte Objekte, auf die über die Wavemaster-Templates zugegriffen
werden kann.
Wie bereits in Kapitel 4.8.1 erwähnt wurde, kann mit den in obiger Tabelle aufgeführten
HW_API-Objekten direkt auf Objekte in der Datenbank des Hyperwave Servers
zugegriffen werden. Beispiel 4.12 soll die Verwendung dieser HW_API Objekte unter
JavaScript verdeutlichen.
// part one:
// create new HW_API_Server-object and identify
var my_server = new HW_API_Server();
my_server.identify({username:”hschwarz”,password”test1”});
// part two:
// get personal home-collection of user hschwarz
// write an error-message, if getting object failed
var out = my_server.object({objectidentifier:”~hschwarz”});
if (out.error.error())
{
writeln(“error getting object”);
for (var x in out.error)
writeln(out.error[x].description(“en”));
}
else
{
// part three:
// insert new attribute in object
var obj = out.object;
obj.insert(new HW_API_Attribute(“Keyword”,”test”));
Kapitel 4: Hyperwave – ein Überblick
50
// part four:
// replace old object with the new one and
// write an error-message, if replacing object failed
out = my_server.replace({objectidentifier:obj.GOid,object:obj});
if (out.error.error())
{
writeln(“Error replacing object!”);
for (var x in out.error)
writeln(out.error[x].description(“en”));
}
}
Beispiel 4.12: Die Änderung eines Objekts am Server erfolgt in vier Schritten.
Beispiel 4.12 zeigt, wie mit Hilfe der HW_API-Objekte unter JavaScript ein HyperwaveObjekt vom Server gelesen, modifiziert und wieder am Server eingefügt werden kann: Am
Beginn des Scripts wird eine Instanz der Klasse HW_API_Server erzeugt, um Zugriff auf
den Server zu erlangen. Nachdem sich ein Benutzer mit entsprechenden Rechten
identifiziert hat, wird ein Objekt vom Server gelesen (im Code als „part two“
gekennzeichnet). Kann der Server das Objekt lesen, so wird dieses in Form einer Instanz
von HW_API_Object in out.object abgelegt. Tritt beim Lesen des Objekts ein Fehler
auf, so wird eine entsprechende Fehlermeldung ausgegeben. Im Fall eines Fehlers liefert
out.error.error() true zurück. Die Fehlerursachen liefert dann out.error in Form
eine Instanz von HW_API_Error zurück. In dem Codeteil, der mit „part three“
gekennzeichnet ist, wird dem ausgelesenen Objekt ein neues Attribut hinzugefügt. Danach
wird das Objekt am Server durch das von dem Script veränderte Objekt ersetzt.(„part
four“) Tritt dabei ein Fehler auf, so wird abermals eine Meldung ausgegeben.
Der Einsatz von JavaScript bietet somit eine sehr mächtige Möglichkeit, um die
Funktionalität und das Verhalten des Hyperwave Information Servers zu verändern. Im
letzten Abschnitt des Kapitel 4 Hyperwave – ein Überblick soll nun noch die Möglichkeit
CGI-Scripts auf einem Hyperwave Information Server auszuführen untersucht werden.
Diese Möglichkeit kann mit dem Commandline-Tool hwjs (siehe Kapitel 4.8.1) kombiniert
werden, um auch auf diese Weise Zugriff auf die Daten des Servers zu erhalten.
4.9 Hyperwave & CGI
Das Common Gateway Interface, kurz CGI, ist ein Interface, um eine externe Applikatione
auf einem Servern zu starten. Ein CGI-Programm wird in real-time am Server gestartet.
Eigabendaten, typischerweise aus den Formularfeldern in HTML-Dateien, können
eingelesen und verarbeitet werden. Das CGI-Script kann auf die Eingabedaten reagieren
und dynamisch Ausgabedaten erzeugen. Abbildung 4.7 zeigt den Ablauf eines CGIAufrufes. Der Benutzer füllt am Client ein Formular aus und schickt es ab. Der Server
erkennt anhand der URL, daß es sich um einen CGI-Aufruf handelt und startet die
entsprechende Applikation. Der Output der Applikation wird vom Server an den Client
zurückgeschickt. [SQ98]
Kapitel 4: Hyperwave – ein Überblick
51
WWW Browser
Server
Application
(on client)
1
CGI
2
Submit completed
form
Call CGI
3
CGI Program's
response
3
CGI Program's
respones
Abbildung 4.7: Der Server erkennt den CGI-Aufruf und startet die entsprechende
Applikation.
Abbildung 4.8: Attribute eines CGI-Objektes
Auch Der Hyperwave Information Server bietet die Möglichkeit, CGI-Scripts am Server
auszuführen. In Hyperwave werden CGI-Programme nicht als Objekte direkt am Server
eingefügt, sondern in einem speziellen Verzeichnis abgelegt. Am Server muß ein
stellvertretendes Objekt erzeugt werden, um das CGI-Programm im Dateisystem zu
referenzieren. Diese Vorgehensweise hat den Vorteil, daß auch CGI-Scripts mit
Hyperwave-Attributen versehen werden können. So kann z.B. durch Vergabe eines
Rechte-Attributes festgelegt werden, welche Benutzer das CGI-Script ausführen dürfen.
Abbildung 4.8 zeigt die Attribute eines solchen stellvertretenden Hyperwave-Objekts.
Dieses Objekt vom Typ "CGI" enthält den Namen und das Verzeichnis des CGIProgramms in seinem Path-Attribut. Um das CGI-Script zu starten, muß die URL des
entsprechenden Objekts angegeben werden. [HwP98]
Kapitel 4: Hyperwave – ein Überblick
52
4.10 Schlußbemerkung
In diesem Kapitel wurden die Eigenschaften des Hyperwave Information Servers sowohl
aus der Sicht des Anwenders, als auch aus der Sicht des Programmierers untersucht. Der
Hyperwave Information Server legt Dokumente in einer Art objektorientierter Datenbank
ab. Jedem Dokument werden dabei bestimmte Metainformationen zugewiesen, die in
Attributen gespeichert werden und die Eigenschaften des entsprechenden Dokuments
beschreiben. Benutzer können sich am System identifizieren und dadurch den vollen
Funktionsumfang des Hyperwave Information Servers nutzen. Durch die Vergabe eines
Rechte-Attributes kann festgelegt werden, welche Benutzer und Benutzergruppen
Zugriffsrechte auf ein bestimmtes Objekt haben. Dabei wurde zwischen read-, write- und
unlink-Rechten unterschieden.
Eine wichtige Eigenschaft des Hyperwave Information Servers ist, daß das Look&Feel der
Benutzeroberfläche gänzlich von den Inhalten der Objekte getrennt wurde. Das
Wavemaster-Modul ist für die optische Darstellung der Objekte zuständig. Das Verhalten
des Hyperwave-Servers kann verändert werden, indem in diese Wavemaster-Templates
eingegriffen wird. Dadurch ist es möglich auf einen Server über zwei unterschiedliche
Wavemaster zuzugreifen, die den Inhalt des Servers völlig verschieden darstellen. Die
Programmierung der Wavemaster-Templates erfolgt mit der Sprache PLACE. Die
Möglichkeiten von PLACE sehr eingeschränkt. Ein viel mächtigeres Konzept, das zur
Programmierung der Wavemaster-Templates eingesetzt werden kann, ist JavaScript. Der
Hyperwave Server erlaubt, aus JavaScript durch eine Reihe von vordefinierten Objekten
direkt auf den Server zuzugreifen.
Im folgenden Kapitel sollen verschiedene Möglichkeit untersucht werden, um eine
hierarchische Benutzerverwaltung unter Hyperwave zu realisieren. Dabei sollen verfügbare
Lösungen und Systeme in Hinblick auf eine hierarchische Benutzerverwaltung untersucht
werden, als auch eigenen Lösungsansätze entwickelt werden, um möglichst viele Varianten
zur Umsetzung einer hierarchischen Benutzerverwaltung zu erhalten. Danach sollen die
Vor- und Nachteile dieser Varianten diskutiert werden, um am Ende des folgenden
Kapitels schließlich ein konkretes Konzept zur Umsetzung einer hierarchischen
Benutzerverwaltung unter Hyperwave ableiten zu können.
Kapitel 5
Lösungssuche
Da in Kapitel 3 die Anforderungen an eine hierarchische Benutzerverwaltung und in
Kapitel 4 die Eigenschaften des Hyperwave Information Servers bereits untersucht
wurden, kann nun mit der Suche nach möglichen Lösungsvarianten zur Implementierung
einer hierarchischen Benutzerverwaltung begonnen werden. Ziel dieses Kapitels ist es, eine
konkrete Lösungsmöglichkeit zu finden, um die in den Systemanforderungen festgelegten
Eigenschaften einer hierarchischen Benutzerverwaltung in die Praxis umsetzen zu können.
Dazu sollen sowohl bereits existierende Lösungen in Bezug auf ein System zur
hierarchischen Benutzerverwaltung untersucht werden, als auch eigene Lösungsansätze
entwickelt werden. Dieses Kapitel wird nach dem in Kapitel 2.5.3 festgelegten PhasenModell der Analysephase zugeordnet. Um die Suche nach einer konkreten
Lösungsmöglichkeit zu erleichtern, soll dieses Kapitel in zwei Abschnitte unterteilt
werden:

Im ersten Abschnitt, der Variantenbildung soll analysiert werden, welche
Möglichkeiten bestehen, um eine hierarchische Benutzerverwaltung zu
implementieren. In dieser Phase sollen möglichst viele Konzepte zur Umsetzung einer
hierarchischen Benutzerverwaltung analysiert werden. Es sollen bereits existierende
Systeme in Hinblick auf eine hierarchischen Benutzerverwaltung untersucht werden,
als auch eigene Konzepte entwickelt werden. Sowohl aus den bereits existierenden
Lösungen als auch aus den eigenen Konzepten sollen Varianten zur Umsetzung eines
Systems zur hierarchischen Benutzerverwaltung abgeleitet werden.

Im zweiten Abschnitt, der Synthese soll aus den möglichen Lösungen, die in der
Variantenbildung untersucht wurden, eine geeignete Lösung für die Umsetzung einer
hierarchischen Benutzerverwaltung auf einem Hyperwave Information Server
abgeleitet werden.
Im folgenden Abschnitt wird daher eine Variantenbildung durchgeführt, um möglichst
viele Möglichkeiten zur Umsetzung einer hierarchischen Benutzerverwaltung untersuchen
zu können.
Kapitel 5: Lösungssuche
54
5.1 Variantenbildung
Aufgabe der Phase „Variantenbildung“ ist, möglichst viele Aspekte zu betrachten, die für
eine geeignete Umsetzung einer hierarchischen Benutzerverwaltung auf einem Hyperwave
Information Server ausschlaggebend sein können. Auch bereits existierende SoftwareSysteme, die eine ähnliche Lösung im Hinblick auf eine hierarchische Benutzerverwaltung
umsetzen, sollen untersucht werden. Bevor in Abschnitt 5.1.2 nach eigenen Möglichkeiten
gesucht werden soll, werden in Abschnitt 5.1.1 bereits bestehende Software-Systeme in
Hinblick auf eine hierarchische Benutzerverwaltung analysiert.
5.1.1 Derzeitige Konzepte
Da in der Literatur kein System gefunden werden konnte, das explizit die Eigenschaften
des in dieser Arbeit auszuarbeitenden Systems einer hierarchischen Benutzerverwaltung
umsetzt, sollen an dieser Stelle System untersucht werden, deren Benutzerverwaltungen
„hierarchische“ Eigenschaften vermuten lassen. An dieser Stelle sollen daher folgende
Systeme untersucht werden:

WindowsNT: Dieses Betriebssystem unterstützt die Vergabe von sogenannten
„Privilegien“, die eventuell zur Umsetzung einer hierarchischen Benutzerverwaltung
genutzt werden könnten.

UNIX:
Das
Betriebsystem
UNIX
soll
aufgrund
seine
vielfältigen
Konfigurationsmöglichkeiten, die auch zur Einbindung einer hierarchischen
Benutzerverwaltung genutzt werden könnten, genauer untersucht werden.

Informix: Informix ist ein mächtiges Datenbanksystem, das Client-Applikationen den
Zugriff auf Datenbanken ermöglicht. Auch Informix setzt Privilegien ein, um
Benutzern besondere Eigenschaften zuzuweisen.
Im Folgenden sollen diese Systeme auf Eigenschaften untersucht werden, die auch zur
Einbindung einer hierarchischen Benutzerverwaltung unter Hyperwave eingesetzt werden
könnten. Dazu soll vor allem auf die Benutzeradministrationen dieser Systeme
eingegangen werden.
Windows NT
Um einem Benutzer zu ermöglichen sich unter WindowsNT22 zu identifizieren, erstellt der
Administrator ein Benutzerkonto. Ein Benutzerkonto ermöglicht einer bestimmten Person
sich mittels eines ihr zugeordneten Anmeldenamens (Login) und eines dazugehörigen
Paßworts unter WindowsNT zu identifizieren. Durch eine erfolgreiche Identifikation
werden dem entsprechenden Benutzer bestimmte Rechte eingeräumt. Benutzer, die sich
zum Beispiel als Gast unter WindowsNT anmelden, besitzen nur sehr wenig Rechte, im
Gegensatz zu Administratoren, die vollständige Kontrolle über das gesamte System
besitzen.
22
http://www.microsoft.com/windows/default.asp
Kapitel 5: Lösungssuche
55
Zu den Angaben eines Benutzerkontos gehören folgende Informationen: [Mab96]

Anmeldenamen

Benutzernamen

Paßwort

Gruppenzugehörigkeit

Zugriffsrechte
Benutzerkonten können mit dem WindowsNT Benutzer-Manager erstellt werden. Um die
Vergabe von Rechten und die Zuweisung von Ressourcen besser kontrollieren zu können
und vor allem die Rechte der einzelnen Benutzer möglichst gleich zu halten, können die
Benutzer zu Gruppen zusammengefaßt werden. Die Benutzer einer Einkaufsabteilung
sollen z.B. das Recht auf einen bestimmten Drucker bekommen. Jedem einzelnen Benutzer
das Recht für den Drucker zuzuweisen, ist umständlich, unübersichtlich und schnell
Ursache für Fehler in der Administration. Durch die Zuordnung der Benutzer zu Gruppen
haben alle Benutzer die gleichen Rechte. Der Gruppe kann jetzt das Recht auf die
Benutzung des Netzwerkdruckers übergeben werden. Benutzergruppen werden ebenfalls
mit dem Benutzermanager erstellt. Danach werden einzelne Benutzer den Gruppen
zugewiesen. [Mab96]
WindowsNT unterstützt die Vergabe von sogenannten Privilegien. Um typische Aufgaben
des Administrators an andere Personen delegieren zu können, ohne diese in die Gruppe der
Administratoren aufnehmen zu müssen, wurden Privilegien eingerichtet. Ein Benutzer
kann so z.B. die Sicherung des Systems übernehmen. Seine Rechte reichen unter normalen
Umständen nicht aus, um auf alle Dateien im System zugreifen zu dürfen. Durch das
Privileg, Sicherungsoperator zu sein, ist es ihm jedoch möglich, alle Daten zu sichern.
Privilegien können auch an ganze Gruppen vergeben werden. Dadurch wird die
Verwaltung der einzelnen Rechte und Benutzer wieder übersichtlicher. [Mab96]
Ein Privileg, das unter WindowsNT vergeben werden kann ist das Privileg des Account
Operators. Account Operators dürfen in der entsprechenden Domäne23 Benutzer und
Benutzergruppen administrieren. Der Account Operator entspricht einem „normalen“
Benutzer ohne Systemrechte, der aber zusätzlich das Recht besitzt neue Benutzer zu
erzeugen. [MR97]
UNIX
Jeder Benutzer besitzt einen Account, der durch eine eindeutige Login-Kennung und UID
festgelegt ist. Login-Namen sind üblicherweise klein geschrieben und besitzen nicht mehr
als 8 Buchstaben. Jedem Benutzer ist außerdem eine eindeutige UID 24 zugeordnet. Diese
23
Um eine größere Anzahl von Windows NT Rechnern in einem Client/Server-Netzwerk
zu verbinden, wurde von Microsoft das Modell der Domäne entwickelt. Eine Domäne faßt
mehrere Server, physikalische Netzwerkabschnitte, Ressourcen (d.h. Drucker, Festplatten
usw.) und Benutzerkonten zu einer zentral administrierbaren Einheit zusammen. [Mab96]
24
User IDentifier
Kapitel 5: Lösungssuche
56
Zahl besitzt einen Wert zwischen 0 und 32767. Nummer unter 1000 sind üblicherweise für
System-Accounts reserviert. Einige typische UIDs für System-Accounts sind in Tabelle 5.1
aufgelistet. [UX99]
UID
Account
Aufgaben
0
root, sysadm, diag
Superuser
1
daemon
Services ohne root-Rechte
2
bin
Kommandos (binaries)
3
uucp
Datentransfer
4
sys
System-Benutzer
5
adm
Administrator
Tabelle 5.1: UIDs für System-Accounts unter UNIX
Die Benutzerdaten werden in der Datei /etc/passwd abgelegt. Diese Datei enthält eine
Liste von Benutzern, die Zugriff zu dem entsprechenden System haben. Jede BenutzerKennung muß in dieser Datei aufscheinen. Beispiel 5.1 zeigt zwei Einträge aus der Datei
/etc/passwd.
arushkin:Igljf78DS:132:20:Amy Rushkin:/usr/people/arushkin:/bin/csh
trsmith:*:543:20:Tent Smith, sys adm:/usr/people/trsmith/:/bin/tcsh
Beispiel 5.1: Einträge in der Datei /etc/passwd
Das erste Feld beinhaltet die Login-Kennung des entsprechenden Benutzers. Das zweite
Feld beinhaltet das Paßwort des Benutzers. In dem Eintrag für arushkin wurde das
Paßwort vom System verschlüsselt und erscheint als eine nichtssagende Folge von
Zeichen. Im Eintrag von trsmith wird dieses Feld von einem Platzhalter besetzt. Das
kann bedeuten, daß der Benutzer kein Paßwort besitzt. [Ux99] Im dritten Feld wird die
UID des Benutzers abgelegt, das vierte Feld beinhaltet die GID25. Die GID ist die
eindeutige Id der Gruppe, welcher der Benutzer zugeordnet ist. Im fünften Feld kann eine
Anmerkung oder Beschreibung zu dem Benutzereintrag festgehalten werden. Das sechste
Feld beinhaltet das Home-Directory des Benutzers. Das letzte Feld beinhaltet die LoginShell. Das ist die Shell, die der Login-Prozeß startet, wenn sich der Benutzer am System
anmeldet. [UX99]
Durch Gruppenzuteilung der Benutzer kann eine übersichtlichere und straffere Verwaltung
der Dateien und Verzeichnisse, und somit eine höhere Datensicherheit erreicht werden.
Benutzergruppen können nach vielfältigen Kriterien bestimmt werden, darunter
Abteilungs- Projekt- und Fachzugehörigkeit, sowie Vertraulichkeitsstufen. Die technische
Verwaltung ist dem Superuser vorenthalten, der die Gruppenkennungen durch Einträge in
25
Group IDentity
Kapitel 5: Lösungssuche
57
der Gruppendatei definiert und somit Gruppenmitgliedschaften vergeben und auch wieder
einziehen kann. Unter UNIX werden zwei Arten von Gruppen und Gruppenzugehörigkeit
unterschieden: [UX99]

Die jeweilige Login-Gruppe eines Benutzers mit automatischer Mitgliedschaft

Die Objekt-Gruppen (Host-Gruppen) mit selektiver Mitgliedschaft.
Die Kennung der Login-Gruppe (LGID) wird als numerischer Kode in das Gruppenfeld in
der Paßwortdatei eingetragen. Jedem Benutzer kann also nur genau eine Login-Gruppe,
mehreren Benutzern jedoch die selbe Login-Gruppe zugewiesen werden. Die LoginGruppe wird unmittelbar nach dem Einloggen zur aktuellen Gruppen-Kennung des
Benutzers. Beispiel 5.2 zeigt die Einträge in der Paßwort- und der Gruppendatei für ein
einfaches Gruppenschema. [UX99]
> cat /etc/passwd
venus:IUZ7655iQ6d:52:12:inner
earth:76576fZTft6:53:12:inner
mars:234h324iuH1:54:12:inner
...
saturn:237gsdfGG38:65:14:outer
uranus:3289Hde98gd:66:14:outer
jupiter:238r8f8oeOQ:67:14:outer
planets:...
planets:...
planets:...
planets:...
planets:...
planets:...
> cat etc/group
inner::12:mercury,earth,mars,...
outer::14:saturn,uranus,jupiter,...
space::16:mercury,earth,mars,saturn,uranus,jupiter,...
Beispiel 5.2: Einträge in der Paßwort- und Gruppendatei
Host-Gruppen können mit bereits existierenden Login-Gruppen zusammenfallen oder als
abstrakte Gruppe neu definiert werden, ohne dabei mit bestimmten Benutzer-Kennungen
assoziiert sein zu müssen. Abstrakte Host-Gruppen werden durch Einträge in der
Gruppendatei /etc/group definiert; Login-Gruppen können zur Benennung eingetragen
werden. In unserem Beispiel stellt space mit GID=16 eine abstrakte Host-Gruppe dar, die
mit keiner UID assoziiert ist, während inner und outer Login-Gruppen in der
Paßwortdatei sind. Die Login-Kennungen (LID) der Benutzer werden in die
Mitgliedslisten der Host-Gruppen eingetragen. Das optionale Gruppen-Paßwort wird nur
beim Gruppenwechsel abgefragt. [UX99]
Merkmale, um eine hierarchische Gliederung von Benutzer- und Gruppenobjekten
vorzunehmen, konnten unter dem Betriebssystem UNIX nicht festgestellt werden. Die
Aufgaben der Benutzerverwaltung können jedoch auch unter Unix ausgelagert werden,
indem bestimmte Benutzer schreibenden Zugriff auf die Dateien /etc/group und
/etc/passwd
erhalten. Diese Benutzer können dann die Aufgaben der
Benutzerverwaltung übernehmen.
Kapitel 5: Lösungssuche
58
Informix
Informix26 ist ein für die Betriebssystemen Unix und WindowsNT verfügbares, objektrelationales27 Datenbanksystem. Dieses Datenbanksystem kann für Online-TransactionProcessing, Data-Warehousing-Anwendung und Web-Lösungen eingesetzt werden. Im
Vordergrund steht der Informix Dynamic Server, der den Zugriff auf darunterliegende
Datenbanken für Client-Applikationen regelt. Der Informix Dynamic Server besitzt eine
Architektur, die sich an die Beschaffenheit des darunterliegenden Systems anpaßt. [Inf99]
An dieser Stelle sollen nun die Eigenschaften dieses Datenbanksystems in Hinblick auf
eine hierarchische Benutzerverwaltung untersucht werden:
a) anlegen von neuen Benutzern:
Wenn ein Benutzer im Rahmen des Infomix-Systems auf eine Datenbank zuzugreifen
versucht, vergleicht der Datenbank-Server das Paßwort, das vom Benutzer angegeben
wurde, mit dem Login-Paßwort des Host-Computers, auf dem der Datenbank-Server
installiert wurde. Diese beiden Paßwörter müssen identisch sein, um Zugriff auf die
Datenbank zu erhalten. Um einen neuen Benutzer zu erzeugen, der auf die das Informix
Datenbanksystem zugreifen darf, muß daher ein neuer Benutzer am Host-Computer
erzeugt werden. Je nachdem, ob der Host-Computer das Betriebssystem UNIX oder
WindowsNT einsetzt, muß dazu wie im Abschnitt „UNIX“ bzw. „WindowsNT“
beschrieben, vorgegangen werden.
b) definieren von Gruppen:
Unter Informix können, wie unter WindowsNT oder auch Hyperwave, Benutzer zu
Gruppen zusammengefaßt werden. Dieses Konzept wird in Informix als Role bezeichnet.
Roles können mit dem SQL-Befehl CREATE ROLE <role-name> erzeugt werden. Diesen
Roles können, genauso wie einzelnen Benutzern, Privilegien auf bestimmte DatenbankObjekte erteilt werden. Wird diese Role bestimmten Benutzern zugewiesen, so erben diese
dadurch die Privilegien der entsprechenden Role.
c) Privilegien:
Die Authorisierung, eine bestimmte Datenbankeigenschaft zu benutzen wird in Informix
als Privileg bezeichnet. Zum Beispiel wird das Privileg eine Datenbank zu lesen als das
Connect Privileg bezeichnet, das Privileg eine neuen Datensatz in eine Tabelle einzufügen
als Insert Privileg. Eine Menge weiterer Privilegien, wie z.B. Access Privileges, TableLevel Privileges oder Colomn-Level Privileges können für bestimmte Benutzer und Roles
vergeben werden, um den Zugriff auf die Datenbank genau zu regeln.
Das Datenbanksystem Informix besitzt keine Eigenschaften, die eine hierarchische
Benutzerverwaltung auf einfache Art und Weise ermöglichen würde. Da die
Benutzerverwaltung dieses Datenbanksystems auch mit dem darunterliegenden
Betriebsystem eng verknüpft ist, scheint eine hierarchische Benutzerverwaltung unter
Informix nur schwer umsetzbar zu sein.
26
27
http://www.informix.com
Objekt-relationale Datenbanksysteme kombinieren die Eigenschaften von relationalen
und objektorientierten Datenbanken.
Kapitel 5: Lösungssuche
59
Schlußfolgerung
Unter WindowsNT existiert das Konzept des Account Operators, das zum Teil der
Funktionalität entspricht, die von der hierarchischen Benutzerverwaltung gefordert wird.
Account Operatoren sind Benutzer, die zwar keine Systemrechte besitzen, jedoch neue
Benutzer im System anlegen dürfen. Dieses Konzept entspricht aber nur zum Teil der für
die hierarchische Benutzerverwaltung geforderten Funktionalität. Der Aufgabenbereich der
Benutzerverwaltung kann mit Hilfe der Account Operatoren zwar aus dem Arbeitsgebiet
der Systemadministratoren losgelöst werden, jedoch ist keine Anordnung der Benutzer in
einer hierarchische Struktur möglich. Eine Möglichkeit, mit der sich auch eine
hierarchische Struktur der Benutzer unter WindowsNT realisieren läßt, wäre die
Benutzerverwaltung nicht über den Benutzermanager von WindowsNT vorzunehmen,
sondern über eigens für diesen Zweck implementierte Perl-Scripts (siehe auch [MR97]). In
diesem Fall könnte auch die „hierarchische Eigenschaft“ der in dieser Arbeit zu
entwickelnden Benutzerverwaltung unter WindowsNT realisiert werden. Diese
Möglichkeit wäre jedoch mit großem Aufwand verbunden.
Das Betriebssystem UNIX besitzt keine Eigenschaften, die für eine hierarchische
Benutzerverwaltung unter Hyperwave adaptiert werden könnten. Trotzdem könnte auch
unter UNIX ein ähnliches System wie unter WindowsNT verwendet werden, um eine
hierarchische Benutzerverwaltung zu ermöglichen. Wiederum müßten zur
Benutzerverwaltung eigene Scripts implementiert werden, mit deren Hilfe Benutzer die
hierarchische Benutzerverwaltung vornehmen können.
Das Datenbanksystem Informix, erlaubt ebenso wie das Betriebssystem WindowsNT, die
Vergabe von Privilegien. Auf Grund von Privilegien können Benutzern innerhalb des
Datenbanksystems
spezielle
Eigenschaften
zugewiesen
werden.
Da
die
Benutzerverwaltung dieses Datenbanksystems jedoch eng mit dem darunterliegenden
Betriebssystem zusammenarbeitet, scheint die Integration einer hierarchischen
Benutzerverwaltung unter Informix jedoch äußerst schwierig zu sein.
Andere Software-Systeme, die ein ähnliches Verhalten, wie das in dieser Arbeit zu
entwickelnde System zur hierarchischen Benutzerverwaltung realisieren, konnten durch
Literaturrecherchen nicht aufgefunden werden.
Nachdem in diesem Abschnitt existierende System auf Eigenschaften untersucht wurden,
die zur Umsetzung einer hierarchischen Benutzerverwaltung unter Hyperwave eingesetzt
werden könnten, sollen im nächsten Abschnitt neue Konzepte entwickelt werden, um die
hierarchische Benutzerverwaltung in einen Hyperwave Information Server einzubinden.
5.1.2 Entwicklung eigener Konzepte
Ziel dieses Abschnittes ist, eigene Konzepte zu entwickeln, um ein System zur
hierarchische Benutzerverwaltung in den Hyperwave Information Server zu integrieren.
Diese Möglichkeiten sollen auf den in Kapitel 4 untersuchten Eigenschaften des
Hyperwave Information Servers aufbauen und zur Variantenbildung beitragen.
Kapitel 5: Lösungssuche
a)
Einbindung
eines
Systems
zur
Benutzerverwaltung in den Hyperwave-Kernel
60
hierarchischen
Eine mögliche Lösungsvariante ist, die hierarchische Benutzerverwaltung direkt ist das
Hyperwave-Kernel einzubinden. Da diese Lösung mit sehr großen zeitlichen und
finanziellen Aufwand verbunden ist, würde sie den Rahmen dieses Projekts sprengen. Falls
sich die in diesem Projekt entwickelte Lösung bewährt und weiterhin der Bedarf an einer
hierarchischen Benutzerverwaltung auch in anderen Hyperwave-Systemen besteht, kann
auf diese Möglichkeit zurückgegriffen werden.
Im weiteren Verlauf dieses Abschnittes werden Konzepte untersucht, die versuchen mit
geringerem Aufwand eine hierarchische Benutzerverwaltung unter Hyperwave
umzusetzen.
b) Implementierung einer hierarchischen Benutzerverwaltung
durch ein Informationsraum-Attribut
Hyperwave ermöglicht es, eine Vielzahl verschiedener Datei-Typen am Server abzulegen.
Dazu zählen HTML-Dateien, Collections, Grafiken, Sound-Dateien, Remote-Dateien,
CGI-Objekte usw. Hyperwave verwendet für alle diese verschiedenen Datei-Typen das
übergeordnete Konzept des Objekts (siehe auch Kapitel 4.2). Auch die Daten der Benutzer
und Benutzergruppen, die für die Benutzerverwaltung unter Hyperwave benötigt werden,
sind in Form von Objekten am Server abgelegt. Eine hierarchische Benutzerverwaltung
kann realisiert werden, indem in diesen Benutzer- und Gruppenobjekten festgehalten wird,
auf welcher Hierarchiestufe sich ein entsprechende Benutzer befindet. Diese Forderung
läßt sich durch die Einführung eines neuen Attributs erfüllen, welches alle Benutzer- und
Gruppenobjekte besitzen müssen. Dieses Attribut wird mit dem Namen InformationsraumAttribut bezeichnet. In diesem Attribut wird die Hierarchiestufe, auf der sich ein Benutzer
befindet, ähnlich wie eine Pfadangabe in einer Verzeichnisstruktur festgehalten. Dieses
Attribut ist zwingend vorgeschrieben und wird beim Anlegen eines neuen Benutzers
automatisch eingefügt. Das Informationsraum-Attribut kann später durch berechtigte
Benutzer editiert werden. Die Hierarchiestufen werden im Informationsraum-Attribut
durch Informationsraum-Namen repräsentiert, die durch „/“- Zeichen voneinander
getrennt werden. Der Inhalt eines Informationsraum-Attributs ergibt sich nach folgenden
Regeln:
Regel 1: Benutzer- und Gruppenobjekte, die sich auf der obersten Hierarchieebene
befinden, besitzen das Informationsraum-Attribut mit dem Wert „/“. Dieser Wert
stellt die Wurzel des gesamten hierarchischen Informationsraum-Systems dar.
Regel 2: Ein Informationsraum-Namen ergibt sich aus einer nichtleeren Zeichenfolge, die
beliebige alphanumerische Zeichen enthalten darf.
Regel 3: Das Informationsraum-Attribut für einen Benutzer auf einer untergeordneten
Hierarchiestufe ergibt sich aus: <Informationsraum-Attribut der
übergeordneten Stufe> + „/” + <Informationsraum-Namen der
untergeordneten Hierarchiestufe>.
Kapitel 5: Lösungssuche
61
CHEF
InfoSpace:/
erzeugt
erzeugt
ABTEILUNGSLEITER_1
InfoSpace://finanz
ABTEILUNGSLEITER_2
InfoSpace://recht
erzeugt
MITARBEITER_1
InfoSpace://finanz/buchhaltung
Abbildung 5.1: Die Hierarchiestufe auf der sich ein Benutzer befindet, wird in dem
Attribut InfoSpace des Benutzerobjekts festgehalten.
Abbildung 5.1 zeigt, nach welchen Regeln neuen Benutzern ein Informationsraum-Attribut
zugeordnet wird. Der Projektadministrator mit der Benutzerkennung Chef, der sich auf der
obersten Hierarchiestufe befindet, besitzt nach Regel 1 das Informationsraum-Attribut /.
Im ersten Schritt erzeugt dieser Benutzer einen neuen Projektadministrator mit dem Namen
Abteilungsleiter_1. Da sich alle neuen Benutzer, die ein bestimmter
Projektadministrator erzeugt, auf einer tieferen Hierarchiestufe befinden als dieser selbst,
muß der Benutzer Chef dem neuen Benutzer beim Anlegen nach Regel 2 einen nichtleeren
Informationsraum zuordnen. Der Benutzer Chef ordnet dem neuen Benutzer den
Informationsraum finanz zu. Das Informationsraum-Attribut des neuen Benutzers erhält
somit nach Regel 3 den Wert //finanz.
Für alle Benutzerobjekte, die sich auf einer tieferen Hierarchiestufe befinden als ein
bestimmter Benutzer ist dieser Benutzer verantwortlich. Das bedeutet, diese
Benutzerobjekte dürfen von dem Benutzer modifiziert und gelöscht werden. Diese Menge
von Benutzern kann leicht durch den Suchbegriff <Wert des InformationsraumAttributs> + „/*” gefunden werden. „*” ist dabei ein Platzhalter für kein oder beliebig
viele Zeichen. Der Benutzer mit der Kennung Abteilungsleiter_1 in obigem Beispiel
darf daher alle Benutzer editieren und löschen, die ein Informationsraum-Attribut gesetzt
haben, das dem Suchbegriff //finanz/* genügt. Der Benutzer Abteilungsleiter_1
darf daher auch den Benutzer Mitarbeiter_1 editieren oder löschen. Allgemeiner
ausgedrückt, ein Benutzer mit dem Informationsraum x ist für alle Benutzer, die dem
Suchbegriff x/* genügen, verantwortlich28. In diesem Bereich darf er neue Benutzer
erzeugen, modifizieren und löschen. Benutzer, die sich auf der gleichen Hierarchiestufe
wie der Benutzer selbst befinden, dürfen von diesem nicht editiert oder gelöscht werden.
28
Im speziellen bedeutet dies, daß Benutzer, die der Informationsraum-Wurzel angehören
für alle Benutzer verantwortlich sind.
Kapitel 5: Lösungssuche
62
c) Hierarchiestufen durch Gruppenobjekte
Eine weitere Methode, um eine hierarchische Benutzerverwaltung unter Hyperwave zu
realisieren wäre, die hierarchische Benutzerverwaltung durch spezielle Gruppenobjekte
aufzubauen. Dabei wird eine Menge von Gruppenobjekten erzeugt, die im Folgenden als
Informationsraum-Gruppen bezeichnet werden. Diese Gruppen zeichnen sich durch ein
spezielles Attribut aus, das sie eindeutig als Informationsraum-Gruppen kennzeichnet.
Informatinsraum-Gruppen sind maßgeblich am Aufbau der Benutzerhierarchie beteiligt.
Die Informationsraumhierarchie wird nach folgenden Regeln aufgebaut:

An der Wurzel der Benutzerhierarchie steht eine Informationsraum-Gruppe, die als
Informationraum-Wurzel bezeichnet wird.

Alle anderen Informationsraum-Gruppen sind Kinder der Informationsraum-Wurzel.

Eine Informationsraum-Gruppe auf einer tieferen Hierarchiestufe hat als Elterngruppe
immer eine Informationsraum-Gruppe auf der nächst-höheren Hierarchiestufe.

Benutzer- und gewöhnliche Gruppenobjekte einer bestimmten Hierarchiestufe sind
Mitglieder der entsprechenden Informationsraum-Gruppe.
Die Benutzerhierachie aus Abbildung 5.1 wird durch diese
Informationsraum-Gruppen Struktur aus Abbildung 5.2 umgeformt.
Regeln
in
die
Benutzer
Gruppe
Chef
Wurzel
Group: wurzel
Group: finanz
Benutzer
Group: recht
Abteilungsleiter_2
Gruppe
Group: recht
recht
Benutzer
Group: ...
Abteilungsleiter_1
Gruppe
Group: finanz
finanz
Group: buchhaltung
Benutzer
Mitarbeiter_1
Group: ...
Gruppe
Group: buchhaltung
buchhaltung
Group: ...
Abbildung 5.2: Eine Informationsraum-Hierarchie
Gruppenobjekte aufgebaut werden.
kann
auch
aus
speziellen
Kapitel 5: Lösungssuche
63
Da in Hyperwave auch verschachtelte Gruppendefinitionen möglich sind (siehe auch
Kapitel 4.3), könnte mit Hilfe der Informatonsraumverwaltung durch Gruppenobjekte eine
Objektzugriffskontrolle realisiert werden. Die Benutzerverwaltung benutzt dabei die
Möglichkeit der verschachtelten Gruppendefinition: Wird einer bestimmten Gruppe der
Zugriff auf ein Objekt gewährt, so dürfen auch die Eltern29 dieser Gruppe auf das Objekt
zugreifen. Abbildung 5.3 zeigt ein Beispiel für eine verschachtelte Gruppendefinition.
Gruppe
Text-Dokument
Gruppe_1
Group: Gruppe_2
Gruppe
Sicherheitshinweise
GOid:
0x01234567_0x01234567
Rights: W: g Gruppe_2
Gruppe_2
Abbildung 5.3: Auch die Eltern einer Gruppe dürfen auf das Objekt zugreifen.
Da der Gruppe Gruppe_2 der Schreib-Zugriff auf das Objekt Sicherheitshinweise
gewährt wird, darf auch dessen Elterngruppe Gruppe_1 auf das Objekt zugreifen. Besitz
aber ein Objekt die Rechte W:g Gruppe_1, so darf Gruppe_2 nicht schreibend auf dieses
Objekt zugreifen. Dieses System kann dazu genutzt werden, allen Benutzern, die sich
näher an der Wurzel der hierarchischen Benutzerverwaltung befinden auch mehr Rechte zu
geben: Sie dürfen auf alle Objekte, für die Benutzern auf tieferen Stufen Zugriffsrechte
haben, auch zugreifen.
Eine hierarchische Benutzerverwaltung, die auf Gruppenobjekten aufbaut, stellt die zweite
in diesem Abschnitt entwickelte Möglichkeit zum Einbinden einer hierarchischen
Benutzerverwaltung in einen Hyperwave Information Server dar. Welche Möglichkeit
konkret genutzt werden soll, muß in der Synthesephase (siehe Kapitel 5.2) entschieden
werden. Bevor jedoch eine konkrete Lösungsmöglichkeit abgeleitet werden kann, muß in
den folgenden Abschnitten noch die Umsetzung der nichtfunktionalen
Systemanforderungen (siehe Kapitel 3.4.2) der hierarchischen Benutzerverwaltung
diskutiert werden.
5.1.3 Sicherheit
Wie bereits in Kapitel 3.4.2 bei der Untersuchung der nichtfunktionalen
Systemanforderungen an eine hierarchischen Benutzerverwaltung erwähnt wurde, muß
sichergestellt werden, daß Benutzer durch Zwischenspeichern und Verändern des HTMLCodes eines Formulars der hierarchischen Benutzerverwaltung nicht gefälschte Daten an
den Server übermitteln können. Würde es einem Benutzer durch Abschicken einer
manipulierten HTML-Seite gelingen auf eine höhere Informationsraum-Ebene zu
gelangen, so könnte er dadurch schließlich bis zur Inforationsraum-Wurzel gelangen und
so Zugriff auf die gesamte Informationsraum-Hierarchie erhalten.
29
engl. Parents
Kapitel 5: Lösungssuche
64
Als Ausgangspunkt für eine sichere Datenübertragung wird die für den Benutzer zur
Informationsraumverwaltung unumgängliche und sichere Identifizierung im System
dienen. Die Daten, die der Server vom Client übernimmt, werden vor dem Ausführen einer
Aktion auf ihre Gültigkeit geprüft. Ordnet z.B. Benutzer1 den Benutzer2 der Gruppe
system30 zu, so wird vor der Ausführung dieser Aktion am Server überprüft ob Benutzer1
das Recht besitzt, Benutzer 2 der Systemgruppe zuzuordnen31. Besitzt Benutzer1 kein
Recht diese Aktion auszuführen, so werden die übermittelten Daten ignoriert und es wird
keine Manipulation des Benutzerobjekts von Benutzer2 am Server durchgeführt Eine
solche Überprüfung muß auch im Fall von Manipulationen des Informationsraum-Attributs
eines Benutzers vorgenommen werden.
5.1.4 Hohe Benutzeranzahl
Eine weitere nichfunktionale Systemanforderung an die hierarchische Benutzerverwaltung
ist die Umsetzung von Mechanismen, die auch bei einer sehr großen Anzahl von
administrierten Benutzern im System eine effiziente Arbeitsweise mit der hierarchischen
Benutzerverwaltung ermöglichen. Dabei muß vor allem das Auflisten aller im System
administrierten Benutzer, wie es in der Standardfunktionalität des Hyperwave Information
Servers vorgenommen wird, vermieden werden. Die Dialoge zur hierarchischen
Benutzerverwaltung sollen dazu um eine Suchfunktion erweitert werden, die es ermöglicht,
nach bestimmten Benutzern zu suchen und so nur einen Teil der administrierten Benutzer
anzuzeigen. Es soll nach der Login-Kennung32, dem Nachnamen und dem
Informationsraum-Attribut von Benutzerobjekten gesucht werden können. Gruppenobjekte
können nach dem Gruppennamen33 und dem Informationsraum-Attribut gesucht werden
(siehe auch Kapitel 3.4.1).
5.1.5 Benutzerfreundlichkeit
Um den Benutzern das Arbeiten mit der neuen Funktionalität der hierarchischen
Benutzerverwaltung zu erleichtern, soll sich das optische Erscheinungsbild und Verhalten
der Dialoge zur hierarchische Benutzerverwaltung an den Standard-Dialogen zur
Benutzerverwaltung orientieren.
Werden vom Benutzer beim Ausfüllen eines Dialogs ungültige Eingaben gemacht, so wird
der Benutzer durch eine entsprechende Meldung darauf hingewiesen. Die Überprüfung der
Benutzereingaben auf ihre Vollständigkeit und Gültigkeit soll bereits am Client erfolgen,
um dadurch wiederholtes Abschicken des Formulars an den Server und die damit
verbundenen Wartezeiten zu verhindern. Diese Funktionalität muß von clientseitigen
JavaScript Funktionen, welche in die Dialoge zur hierarchischen Benutzerverwaltung
30
Benutzer, die der Gruppe system angehören, besitzen Systemrechte.
31
Im Extremfall könnte Benutzer 1 versuchen, durch das Abschicken einer manipulierten
HTML-Seite sich selbst der Systemgruppe zuzuordnen.
32
UName-Attribut
33
UGroup-Attribut
Kapitel 5: Lösungssuche
65
eingebunden werden, übernommen werden. Aufgabe dieser Funktionen ist das Überprüfen
der Benutzereingaben auf ihre Gültigkeit und Vollständigkeit. Sind die Benutzereingaben
ungültig oder nicht vollständig, so wird eine JavaScript-Messagebox geöffnet, die den
Benutzer auf diesen Umstand hinweist.
5.1.6
Zusammenfassung
In diesem Abschnitt wurde eine Reihe von Konzepten untersucht, um eine hierarchische
Benutzerverwaltung in einen Hyperwave Information Server integrieren zu können. Im
ersten Schritt wurden bereits existierende Lösungen analysiert, um sie auf ihre
Wiederverwendbarkeit für das Hyperwave-System zu untersuchen. Es wurden die beiden
Betriebssysteme WindowsNT und UNIX in Hinblick auf eine hierarchische
Benutzerverwaltung untersucht. Unter WindowsNT konnte das Konzept des Account
Operators gefunden werde, das gewisse Gemeinsamkeiten mit den Eigenschaften eines
Systems zur hierarchischen Benutzerverwaltung aufweist. Ein Account Operator ist ein
Benutzer ohne Systemrechte, der dazu berechtigt ist, neue Benutzer im System anzulegen.
Weiters wurde das Datenbanksystem Informix auf Eigenschaften einer hierarchischen
Benutzerverwaltung untersucht. Informix unterstützt das Konzept der Roles, mit dem
Privilegien für Benutzer im Rahmen des Informix-Systems vergeben werden können.
Im Anschluß daran wurden neue Konzepte entwickelt, um ein hierarchische
Benutzerverwaltung unter Hyperwave umzusetzen. Die Daten, die zum Aufbau der
Benutzerhierarchie benötigt werden, können direkt in den Benutzer- und Gruppenobjekten
in Form eines Attributes festgehalten werden. Die zweite Möglichkeit, die aufgezeigt
wurde ist, die Benutzerhierarchie durch spezielle Gruppenobjekte aufzubauen.
Nachdem in diesem Abschnitt die wichtigsten Eigenschaften und Konzepte untersucht
wurden, um ein System zur hierarchischen Benutzerverwaltung auf einem Hyperwave
Server zu realisieren, soll im nächsten Abschnitt eine konkrete Möglichkeit unter
Zuhilfenahme der in diesem Abschnitt besprochenen Konzepte ausgewählt werden, um die
hierarchische Benutzerverwaltung in die Praxis umsetzen zu können.
5.2 Synthese
Aufgabe der Synthesephase ist, unter Zuhilfenahme der in Abschnitt 5.1 diskutierten
Konzepte und analysierten Lösungen eine konkrete Möglichkeit abzuleiten, um eine
hierarchische Benutzerverwaltung auf einem Hyperwave Information Server umzusetzen.
Die ausgewählte Lösung muß dabei die in Kapitel 3.4 festgelegten Systemanforderungen
erfüllen.
Um eine Entscheidung treffen zu können, welches der in der Variantenbildung
untersuchten Konzepte am Besten zur Umsetzung einer hierarchischen
Benutzerverwaltung unter Hyperwave geeignet ist, sollen die Vor- und Nachteile der
einzelnen Konzepte anhand einer Tabelle bewertet werden. Dabei sollen die Konzepte
nach folgenden Kriterien bewertet werden:

Realisierbarkeit: Ist eine hierarchische Benutzerverwaltung durch dieses Konzept
überhaupt realisierbar?
Kapitel 5: Lösungssuche
66

Privilegierte Benutzer: Können mit dem entsprechenden Konzept privilegierte
Benutzer erzeugt werden, welche die Aufgabe der Benutzerverwaltung übernehmen?

Adaptierbarkeit: Ist das entsprechende Konzept für Hyperwave adaptierbar?

Einfachheit: Ist das entsprechende Konzept unter Hyperwave mit geringem Aufwand
umsetzbar?

Zugriffskontrolle: Kann das entsprechende Konzept so erweitert werden, daß evtl.
auch eine Zugriffskontrolle damit realisiert werden kann?
System auf Zugriffskontrolle erweiterbar
einfach umzusetzen
System für Hyperwave
einfach adaptierbar
Konzept
technisch realisierbar
unterstützt privilegierte
Benutzer
Tabelle 5.2 zeigt die Bewertung der untersuchten Konzepte anhand dieser Kriterien.
WindowsNT
Ja
Ja
Nein
Nein
Nein
UNIX
Ja
(Ja)34
Nein
Nein
Nein
Informix
Nein
Ja
Nein
Nein
Nein
Attribut
Ja
Ja
Ja
Ja
Nein
Gruppen
Ja
Ja
Ja
Nein
Ja
Tabelle 5.2: Kriterien, um ein geeignetes Konzept zur Umsetzung einer hierarchischen
Benutzerverwaltung unter Hyperwave zu auszuwählen.
Da die Möglichkeit die hierarchische Benutzerverwaltung über eine Gruppenstruktur zu
realisieren eindeutig mit mehr Aufwand verbunden ist als die Möglichkeit die
hierarchische Benutzerverwaltung durch ein zusätzliches Attribut in den Benutzer- und
Gruppenobjekten umzusetzen, soll die hierarchische Benutzerverwaltung durch diese
Möglichkeit realisiert werden. Insbesondere waren folgende Gründe ausschlaggebend,
warum die Möglichkeit die hierarchische Benutzerverwaltung durch ein zusätzliches
Attribut in des Benutzer- und Gruppenobjekten umzusetzen ausgewählt wurde:

34
Alle Systemanforderungen an eine hierarchische Benutzerverwaltung können durch
diese Lösung einfach umgesetzt werden.
UNIX unterstützt keine Privilegien im eigentlichen Sinne. Es lassen sich jedoch durch
die Vergabe von Gruppenrechten privilegierte, d.h. mit speziellen Rechten ausgestattete
Benutzer erzeugen, die bestimmte Aufgaben im System, wie z.B. Systembackup, PrinterKonfiguration, usw. übernehmen können.
Kapitel 5: Lösungssuche
67

Die Umsetzung der hierarchischen Benutzerverwaltung durch ein InformationsraumAttribut ist unter Hyperwave mit relativ wenig Aufwand realisierbar.

Diese Lösung kann einfach erweitert werden.
Beim technischen Entwurf einer hierarchischen Benutzerverwaltung, wie sie in Kapitel 6
vorgenommen werden soll, müssen auch die nichtfunktionalen Systemeigenschaften der
hierarchischen Benutzerverwaltung, die in Abschnitt 5.1.3 bis 5.1.5 diskutiert wurden,
berücksichtigt werden.
5.3 Schlußbemerkung
Aufgabe dieses Kapitels war die Bildung möglichst vieler Lösungsvarianten und das
Auswählen
einer
konkreten
Lösungsmöglichkeit,
um
die
hierarchischen
Benutzerverwaltung in die Praxis umzusetzen. Im ersten Schritt wurde untersucht, welche
bereits existierenden Softwaresysteme eine ähnliche Funktionalität umsetzten. Dabei
wurden die Benutzerverwaltungen von den Betriebssystemen WindowsNT und Unix,
sowie dem Datenbanksystem Informix näher betrachtet. Im zweiten Schritt wurden neue
Möglichkeiten gesucht, die sich zur Umsetzung einer hierarchischen Benutzerverwaltung
unter Hyperwave eignen. Dabei wurden die Möglichkeiten die hierarchische
Benutzerverwaltung über ein neues Attribut in den Benutzerobjekten und eine
Gruppenhierarchie zu implementieren näher untersucht. Danach wurden noch andere
wichtige
Eigenschaften
der
hierarchischen
Benutzerverwaltung,
wie
Benutzerfreundlichkeit und Systemsicherheit behandelt. In der Synthesephase wurde
schließlich eine konkrete Lösungsvariante zur Umsetzung einer hierarchischen
Benutzerverwaltung ausgewählt.
Die Diskussion der einzelnen Systemaspekte erfolgte dabei möglichst
Implementierungsunabhängig. Es wurde weder auf die zu verwendende
Programmiersprache, noch auf Implementierungsdetails eingegangen. Nachdem mit
diesem Kapitel der Untersuchungsbereich dieser Arbeit abgeschlossen wurde, beginnt mit
dem nächsten Kapitel „Technischer Entwurf der ausgewählten Variante“ der
Gestaltungsbereich der vorliegenden Arbeit. Im Gestaltungsbereich soll das in diesem
Kapitel ausgewählte Konzept zur Umsetzung einer hierarchischen Benutzerverwaltung in
die Praxis umgesetzt werden. Der Gestaltungsbereich gliedert sich nach den in Kapitel 2
festgelegten Projektphasen Design, Implementierung Test und Integration.
Gestaltungsbereich
Im Gestaltungsbereich sollen die im Untersuchungsbereich erzielten Ergebnisse in Form
einer Implementierung in JavaScript in das bestehende Hyperwave Standardinterface
eingebunden werden. Die im Standardinterface enthaltenen Dialoge werden einer
hierarchischen Benutzerverwaltung entsprechend angepaßt und erweitert. Die
Implementierung soll objektorientiert und möglichst modular aufgebaut werden, um für
ähnliche Anwendungen einfach adaptiert werden zu können.
Kapitel 6
Technischer Entwurf der ausgewählten
Variante
6.1 Einleitung
Voraussetzungen, um mit dem technischen Entwurf des Projekts beginnen zu können, sind
vollständige und vom Auftraggeber akzeptierte Systemanforderungen (siehe Kapitel 3),
sowie ein abgeschlossener Untersuchungsbereich für das vorliegende Problem (siehe
Kapitel 5). Nachdem am Ende des Untersuchungsbereichs eine konkrete
Lösungsmöglichkeit für eine hierarchische Benutzerverwaltung abgeleitet wurde, kann nun
mit dem technischen Entwurf dieser Lösung begonnen werden.
Im ersten Abschnitt des vorliegenden Kapitels wird recherchiert, welche technischen
Möglichkeiten zur Verfügung stehen, um ein System zur hierarchischen
Benutzerverwaltung in die Funktionalität des Hyperwave Information Servers einzubinden.
Eine hierarchische Benutzerverwaltung kann durch die Programmiersprache PLACE,
durch CGI-Objekte, oder durch SSJS in Hyperwave eingebunden werden. Nachdem eine
konkrete Möglichkeit ausgewählt wurde, kann mit dem technischen Entwurf eines Systems
zur hierarchischen Benutzerverwaltung begonnen werden. Der Entwurf erfolgt in zwei
Schritten. Im ersten Schritt erfolgt das Design der Benutzeroberfläche und der
clientseitigen JavaScript-Funktionen. Aufgabe der clientseitigen Funktionen ist, vor dem
Absenden eines Formulars schon am Client die von Benutzer eingegebenen Daten auf ihre
Gültigkeit zu überprüfen. Im zweiten Schritt werden die Objekte für die serverseitige
Funktionalität der hierarchischen Benutzerverwaltung abgeleitet. Der Entwurf der Objekte
erfolgt nach den Prinzipien des OOD35 und orientiert sich dabei an der Methode nach
Booch.[Boo92]
Nachdem sowohl die zur Umsetzung einer hierarchischen Benutzerverwaltung benötigte
Funktionalität als auch die dazugehörenden Benutzerdialoge entworfen wurden, soll
35
Objektorientiertes Design (siehe auch Kapitel 6.8)
Kapitel 6: Technischer Entwurf der ausgewählten Variante
schließlich geklärt werden, wie die Scripts, die unter Einsatz der im vorigen Schritt
entworfenen Objekte, Anfragen an die hierarchische Benutzerverwaltung umsetzen,
ablaufen.
Im letzten Abschnitt dieses Kapitels wird schließlich ein Projektplan für die
Implementierungsphase der hierarchischen Benutzerverwaltung erstellt. Dieser Projektplan
gibt an, in welcher Reihenfolge die in diesem Kapitel entworfenen Objekte und Dialoge
entworfen werden sollen und Überprüft die in Kapitel 2.5.1 durchgeführte
Aufwandsabschätzung für die Implementierungsphase.
6.2 Einbindung der hierarchischen
Benutzerverwaltung in Hyperwave
Bevor mit dem technischen Entwurf des Systems begonnen werden kann, muß geklärt
werden, auf welche Art die hierarchische Benutzerverwaltung in den Hyperwave
Information Server eingebunden werden soll. Hyperwave stellt mehrere Möglichkeiten zu
Verfügung, um die Funktionalität des Servers zu erweitern (siehe auch Kapitel 4.7 bis
Kapitel 4.9):

Neue Dialoge und Funktionen können mittels PLACE in die Wavemaster-Templates
eingebunden werden.

Neue Dialoge und Funktionen können mittels serverside JavaScript in die WavemasterTemplates eingebunden werden.

Neue Funktionalität kann durch den Aufruf von CGI-Objekten dem Hyperwave Server
hinzugefügt werden.
Da die von PLACE angebotene Funktionalität nicht ausreicht, um die komplexen
Aufgaben, die durch die hierarchische Benutzerverwaltung umgesetzt werden müssen, zu
erfüllen, scheidet diese Möglichkeit aus. Die Einbindung der hierarchischen
Benutzerverwaltung muß daher entweder, wie in Möglichkeit zwei beschrieben, über
SSJS-Funktionen in den Wavemaster-Templates oder nach Möglichkeit drei, über CGIScripts, erfolgen. Möglichkeit drei erfordert neben dem Einbinden der für die hierarchische
Benutzerverwaltung benötigten Scripts in das CGI-Verzeichnis des Hyperwave
Information Servers auch das Anlegen von CGI-Objekten am Server, welche die
entsprechenden Scripts referenzieren (siehe Kapitel 4.9). Ein weiterer Nachteil dieser
Möglichkeit ist, daß durch das Starten der vom CGI-Objekt angesprochenen Anwendung
die Performance des Systems negativ beeinflußt wird, da zusätzliche Ressourcen
verbraucht werden. Aus diesem Grund wird Möglichkeit zwei (SSJS) vorgezogen, um die
hierarchische Benutzerverwaltung in den Hyperwave Server einzubinden. Wird die neue
Funktionalität über JavaScript in den Wavemaster-Templates in den Server integriert, so
müssen bei erneuter Installation der hierarchischen Benutzerverwaltung nur die
entsprechenden Wavemaster-Templates auf dem neuen Server eingebunden werden.
Nachdem an dieser Stelle geklärt wurde, durch welche technische Möglichkeit die
hierarchische Benutzerverwaltung in den Hyperwave Information Server eingebunden
70
Kapitel 6: Technischer Entwurf der ausgewählten Variante
werden soll, wird im nächsten Abschnitt detailliert auf das Zusammenspiel der einzelnen
Dialoge und Funktionen der hierarchischen Benutzerverwaltung eingegangen.
6.3 Dialoge & Funktionen der hierarchischen
Benutzerverwaltung
Wie in Kapitel 3.4.2 bereits erwähnt wurde, sollen das Verhalten der hierarchischen
Benutzerverwaltung an das Verhalten des Hyperwave Standard-Interfaces angepaßt
werden. Dadurch soll dem Benutzer der Umgang mit der neuen Funktionalität der
hierarchischen
Benutzerverwaltung
erleichtert
werden.
Die
hierarchische
Benutzerverwaltung muß die in Kapitel 3.4.1 aufgelisteten Dialoge und Funktionen
umsetzten. Die angebotene Funktionalität wird in die Funktionsgruppen „Benutzer
einfügen, editieren und löschen“, „Gruppen einfügen, editieren und löschen“ und
„Benutzer zu Gruppen zuordnen“ unterteilt. Im diesem Kapitel sollen im ersten Schritt die
Dialoge des Standard-Interfaces zur Benutzer- und Gruppen-Administration untersucht
werden. Aus den daraus gewonnenen Ergebnissen können schließlich die Dialoge zur
hierarchischen Benutzerverwaltung und deren Interaktionen untereinander abgeleitet
werden. Im ersten Schritt soll durch Event-Diagramme analysiert werden, welche
Möglichkeiten das Standard-Interface dem Anwender bietet, um die Benutzer- und
Gruppenverwaltung am Server durchzuführen und wie die dafür benötigten Dialoge vom
Benutzer aufgerufen werden können.
71
Kapitel 6: Technischer Entwurf der ausgewählten Variante
72
1.2.1. Dialog:
neuen Benutzer anlegen
Cancel
neuer Benutzer
1.1.1.Benutzer anlegen
Benutzer
anzeigen
E
OK
OK
1.1.3. Benutzer löschen
Delete
Cancel
1.2.2. Dialog:
Benutzer auflisten
OK
1.1.2. Attribute ändern
More
1.2.3. Dialog:
Attribute anzeigen
Abbildung 6.1: Event-Diagramm der Funktionsgruppe „Benutzer anlegen, editieren und
löschen“
Der Benutzer kann über den Menüpunkt „Admin/Benutzer“ des Standard-Interfaces die
Dialoge zur Verwaltung von Benutzern aufrufen. Dabei kann der Menüpunkt „neuer
Benutzer“ gewählt werden, um einen Dialog zum Anlegen eines neuen Benutzers
aufzurufen. Wird der Button „OK“ geklickt, so wird ein neuer Benutzer mit den vom
Anwender angegeben Daten am Server angelegt Der Menüpunkt „Benutzer anzeigen“
listet alle momentan im System administrierten Benutzer auf. Durch Auswählen
bestimmter Benutzer durch Anklicken der Checkbox und anschließendes drücken des
„Delete“-Buttons werden die ausgewählten Benutzer gelöscht. Der Button „Edit“ öffnet
einen Dialog zum Editieren von Benutzerdaten. Abbildung 6.1 zeigt in einem EventDiagramm, wie die entsprechenden Dialoge zur Verwaltung von Benutzerobjekten
aufgerufen werden können und welche Aktionen dem Benutzer zur Verfügung stehen.
Analog können über den Menüpunkt „Admin/Gruppen“ des Standard-Interfaces die
Dialoge zur Verwaltung von Gruppen aufgerufen werden. Die Dialoge zur Verwaltung von
Gruppen verhalten sich sehr ähnlich zu den Benutzer-Dialogen. Den einzigen Unterschied
bildet der „List“-Button im „Attribute anzeigen“-Dialog für Gruppen, der alle einer
bestimmten Gruppe zugewiesenen Benutzer auflistet. Abbildung 6.2 zeigt das EventDiagramm für die Verwaltung von Gruppen.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
73
2.2.1. Dialog:
neuen Gruppe anlegen
Cancel
neue Gruppe
2.1.1.Gruppe anlegen
Gruppen
anzeigen
E
OK
OK
2.1.3. Gruppe löschen
Delete
Cancel
2.2.2. Dialog:
Gruppen auflisten
OK
2.1.2. Attribute ändern
More
2.2.3. Dialog:
Attribute anzeigen
List
2.2.3. Dialog:
Attribute anzeigen
Abbildung 6.2: Das Event-Diagramm der Funktionsgruppe „Gruppen anlegen, editieren
und löschen“ besitzt den zusätzlichen Dialog „Benutzer auflisten“
Die dritte Funktionsgruppe, die dem Anwender im Standard-Interface des Hyperwave
Servers im Rahmen der Benutzerverwaltung zur Verfügung steht, ist die Funktionsgruppe
„Benutzer zu Gruppen zuordnen“. Diese Funktionsgruppe wird über den Menüpunkt
„Admin/Gruppen/Benutzer zuordnen...“ ausgewählt. Dieser Menüpunkt öffnet einen
Dialog, der es ermöglicht, Benutzer zu Gruppen zuzuordnen bzw. Benutzern aus Gruppen
zu löschen. Abbildung 6.3 zeigt das Event-Diagramm dieser Funktionsgruppe.
Nachdem nun die Dialoge des Standard-Interfaces zur Benutzerverwaltung analysiert
wurden, sollen im nächsten Schritt die Dialoge zur hierarchischen Benutzerverwaltung
entworfen werden. Das Verhalten der Dialoge zur hierarchischen Benutzerverwaltung soll
sich an den zuvor analysierten Dialogen des Hyperwave Standard-Interfaces orientieren.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
74
Benutzer/Gruppen
zuordnen
3.1.1. Benutzer/Gruppen
zuordnen
3.1.2. Benutzer aus
Gruppen löschen
3.2.1. Dialog:
Benutzer/Gruppen
zuordnen
OK
Cancel
E
3.2.2. Dialog:
Benutzer aus
Gruppen löschen
OK
Cancel
E
Abbildung 6.3: Eventdiagramm der Funktionsgruppe „Benutzer zu Gruppen zuordnen“
Im wesentlichen müssen drei Änderungen vorgenommen werden, um die Standard-Dialoge
an die hierarchische Benutzerverwaltung anzupassen:
1) Die Dialoge zum Anlegen von neuen Benutzern sowie Gruppen bzw. die Dialoge zum
Editieren von Benutzern und Gruppen müssen Eingabefelder zur Verfügung stellen,
um die in Kapitel 3.4.1 vorgeschriebenen Attribute angeben bzw. ändern zu können.
2) Die Dialoge zum Anzeigen aller Benutzer und aller Gruppen sowie der Dialog zum
Zuweisen von Benutzern zu Gruppen müssen die in Kapitel 3.4.1 besprochene
Suchfunktionalität anbieten.
3) Für die Dialoge der hierarchischen Benutzerverwaltung müssen neue Server-Actions
definiert werden, die am Server die notwendigen Scripts zur hierarchischen
Benutzerverwaltung anstoßen (siehe auch Kapitel 4.7).
Zunächst werden diese Änderungen für die Funktionsgruppe „Benutzer anlegen, editieren
und löschen“ dargestellt. Die Durchführung dieser Änderungen führt zu dem in Abbildung
6.4 dargestellten Event-Diagramm. Dieser Abbildung wurden auch die Namen der ServerActions für den Aufruf von Funktionen aus dieser Funktionsgruppe hinzugefügt.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Cancel
1.2.1. Dialog:
neuen Benutzer anlegen
75
A1
neuer Benutzer
1.1.1.Benutzer anlegen
Benutzer
anzeigen
E
OK
OK
A3
A2
A5
A3
1.1.3. Benutzer löschen
Cancel
1.2.2. Dialog:
Benutzer auflisten
Delete
A4
OK
A3
1.1.2. Attribute ändern
1.1.4 Benutzer suchen
More
A6
Suchen
1.2.3. Dialog:
Attribute anzeigen
A1
dialog.ni_new user.action
A4
dialog.ni_changeuser.action
A2
dialog.ni_insertnew user.action
A5
dialog.ni_deleteuser.action
A3
dialog.ni_listuser.action
A6
dialog.ni_edituser.action
Abbildung 6.4: Die Funktionsgruppe „Benutzer anlegen, editieren und löschen“ wird im
Rahmen der hierarchischen Benutzerverwaltung um eine Suchfunktion erweitert.
Die für die hierarchische Verwaltung von Benutzerobjekten definierten Server-Actions
werden zur besseren Übersicht in Tabelle 6.1 aufgelistet. Auf die Funktionalität, die der
Server umsetzen muß, um auf diese Server-Actions zu reagieren, wird in Abschnitt 6.5
genauer eingegangen.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Aktion
Name der Server-action
A1
Dialog „Neuen Benutzer anlegen“
dialog.ni_newuser.action
A2
Aktion „Neuen Benutzer anlegen“
dialog.ni_insertnewuser.action
A3
Dialog „Benutzer anzeigen“
dialog.ni_listuser.action
A5
Aktion „Benutzer löschen“
dialog.ni_deleteuser.action
A6
Dialog „Benutzer editieren“
dialog.ni_edituser.action
A4
Aktion „Benutzer editieren“
dialog.ni_changeuser.action
Tabelle 6.1: Jede ausführbare Aktion wird einer eigenen Server-Action zugeordnet.
Der Entwurf der Dialoge der Funktionsgruppe „Gruppen anlegen, editieren und löschen“
erfolgt analog, das Verhalten orientiert sich ebenfalls an den Standard-Dialogen der
Hyperwave-Benutzeroberfläche. Wie man Abbildung 6.5 entnehmen kann, wurde der
Dialog zum Auflisten aller Gruppen im Rahmen der hierarchischen Benutzerverwaltung
ebenfalls um eine Suchfunktion erweitert, um die angezeigten Gruppenobjekte
einschränken zu können. Auch Abbildung 6.5 wurden bereits die für die Verwaltung von
Gruppenobjekten definierten Server-Actions hinzugefügt.
76
Kapitel 6: Technischer Entwurf der ausgewählten Variante
2.2.1. Dialog:
neuen Gruppe anlegen
Cancel
77
A1
neue Gruppe
2.1.1.Gruppe anlegen
Gruppen
anzeigen
E
OK
OK
A3
A2
2.1.3. Gruppe löschen
A5
A3
Cancel
2.2.2. Dialog:
Gruppen auflisten
Delete
A4
OK
A3
A6
2.1.2. Attribute ändern
More
1.1.4 Benutzer suchen
Suchen
A6
2.2.4. Dialog:
Benutzer auflisten
2.2.3. Dialog:
Attribute anzeigen
OK
A7
List
A1
dialog.ni_new groupaction
A5
dialog.ni_deletegroupr.action
A2
dialog.ni_insertnew groupr.action
A6
dialog.ni_editgroupr.action
A3
dialog.ni_listgroupr.action
A7
dialog.ni_show groupmembers.action
A4
dialog.ni_changegroupr.action
Abbildung 6.5: Die Funktionsgruppe „Gruppen anlegen, editieren und löschen“ im
Rahmen der hierarchischen Benutzerverwaltung
Zur besseren Übersicht wird die Bedeutung der in Abbildung 6.5 definierten ServerActions zur Verwaltung von Gruppen nochmals in Tabelle 6.2 angeführt.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Aktion
78
Name der Server-action
A1
Dialog „Neue Gruppe anlegen“
dialog.ni_newgroup.action
A2
Aktion „Neue Gruppe anlegen“
dialog.ni_insertnewgroup.action
A3
Dialog „Gruppen anzeigen“
dialog.ni_listgroups.action
A5
Aktion „Gruppe löschen“
dialog.ni_deletegroups.action
A6
Dialog „Gruppe editieren“
dialog.ni_editgroup.action
A4
Aktion „Gruppe editieren“
dialog.ni_changegroup.action
A7
Zur Gruppe zugeordnete Benutzer
dialog.ni_showgroupmembers.action
Tabelle 6.2: Für die Funktionsgruppe „Gruppen anlegen, editieren und löschen“ werden
sieben Server-Actions definiert.
Auch die Funktionsgruppe „Benutzer zu Gruppen zuordnen“ wird im Rahmen der
hierarchischen Benutzerverwaltung um eine Suchfunktionalität erweitert. Dabei muß
beachtet werden, daß dieser Funktionsgruppe sowohl eine Suchfunktion für Benutzer als
auch für Gruppen zur Verfügung stellen muß. Diese Erweiterung führt zu dem in
Abbildung 6.6 gezeigten Event-Diagramm. Die Server-Actions, die für diese Komponente
definiert wurden, sind in Tabelle 6.3 aufgelistet.
Benutzer/Gruppen
zuordnen
3.2.1. Dialog:
Benutzer/Gruppen
zuordnen
OK
3.1.2. Benutzer aus
Gruppen löschen
A1
3.1.1. Benutzer/Gruppen
zuordnen
A2
3.2.2. Dialog:
Benutzer aus
Gruppen löschen
OK
A3
A1
Cancel
1.1.4 Gruppen/Benutzer
suchen
Suchen
E
A1
dialog.ni_assign_u_g.action
A2
dialog.ni_add_u_g.action
Cancel
A3
E
dialog.ni_remove_u_g.action
Abbildung 6.6: Event-Diagramm der Funktionsgruppe „Benutzer zu Gruppen zuordnen“
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Aktion
Name der Server-action
Dialog „Benutzer zu Gruppen zuordnen“
dialog.ni_assign_u_g.action
Aktion „Benutzer zu Gruppen zuordnen“
dialog.ni_add_u_g.action
Aktion „Benutzer aus Gruppen löschen“
dialog.ni_remove_u_g.action
Tabelle 6.3: Für die Funktionsgruppe „Benutzer zu Gruppen zuordnen werden drei neue
PLACE-acions definiert.
Nachdem in diesem Kapitel das Verhalten der Dialoge zur hierarchischen
Benutzerverwaltung geklärt wurde, soll im nächsten Kapitel die grafische Oberfläche der
Dialoge zur hierarchischen Benutzerverwaltung entworfen werden.
6.4 Gestaltung der Dialoge zur
hierarchischen Benutzerverwaltung
Die Gestaltung der Dialoge zur hierarchischen Benutzerverwaltung soll exemplarisch an
den Beispielen „neuen Benutzer anlegen“ und „Benutzerobjekte auflisten“ erfolgen. Die
Gestaltung aller weiteren Dialoge folgt demselben Schema. Im ersten Schritt soll der
Dialog zum Anlegen eines neuen Benutzers entworfen werden. Der Entwurf des Dialogs
orientiert sich am entsprechenden Dialog des Hyperwave Standard-Interfaces zum
Einfügen eines Benutzers. Abbildung 6.7 zeigt diesen Dialog.
Im wesentlichen müssen nun drei Änderungen vorgenommen werden, um die Dialog zum
Anlegen eines neuen Benutzers für die hierarchische Benutzerverwaltung zu adaptieren:

Die Eingabemaske des Dialogs muß so abgeändert werden, daß alle notwendigen 36 und
wahlfreien Attribute, die eine Benutzers im Rahmen der hierarchischen
Benutzerverwaltung besitzen kann, angegeben werden können.

Der „erweitert...“ -Button zum Anzeigen eines erweiterten Dialoges, um einen
neuen Benutzer anzulegen, muß entfernt werden. Im Rahmen der hierarchischen
Benutzerverwaltung ist ein solcher Dialog nicht vorhanden.

Die clientseitige Funktion zum Überprüfen der vom Benutzer eingegebenen Daten auf
ihre Gültigkeit muß hinzugefügt werden.
36
Alle notwendigen Attribute werden durch einen Stern neben dem entsprechenden
Eingabefeld im Dialog gekennzeichnet.
79
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Abbildung 6.7: Der Standard-Dialog zum Anlegen eines neuen Benutzers.
Um den Dialog zum Anlegen eines neuen Benutzers an die hierarchische
Benutzerverwaltung anzupassen, müssen die Attribute, die beim Anlegen eines neuen
Benutzers angegeben werden müssen, gegen die in Kapitel 3.4.1 angeführten Attribute
getauscht werden. Eine besondere Rolle spielt das Attribut „Informationsraum“, das die
Hierarchieebene, auf der sich ein entsprechende Benutzer befindet, festlegt. Dieses Attribut
besitzt bereits einen „vorausgefüllten“ Teil, der im Dialog vor dem eigentlichen
Eingabefeld angegeben wird. Der Benutzer muß dieses Attribut erweitern, um einen neuen
Benutzer anlegen zu können. Beim Abschicken des Formulars werden der vorausgefüllte
Teil und der vom Benutzer angegebene Teil zu einem einzigen Attribut verschmolzen. Im
Rahmen der hierarchischen Benutzerverwaltung besteht auch die Möglichkeit, neue
Attribute in Form von Key-Value Paaren anzugeben. Dazu kann die letzte Eingabezeile im
Dialog verwendet werden. Die optische Gestaltung und die Anordnung der einzelnen
Elemente werden von dem Standard-Dialog übernommen. Abbildung 6.8 zeigt den Dialog
zum Anlegen eines neuen Benutzers im Rahmen der hierarchischen Benutzerverwaltung.
80
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Abbildung 6.8: Der „neuer Benutzer“-Dialog für die hierarchische Benutzerverwaltung
Weiters wird dieser Dialog um eine clientseitige JavaScript-Funktion erweitert, welche die
in Kapitel 3.4 angesprochene Überprüfung der eingegebenen Daten, soweit möglich,
bereits am Client vornimmt.
81
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Die Aufgaben dieser clientseitigen JavaScript-Funktion37 sind:

Überprüfen, ob alle notwendigen Formularfelder ausgefüllt wurden.

Überprüfen, ob das Format der eingegebenen Daten gültig ist.

Falls eine dieser beiden Forderungen nicht erfüllt ist, wird eine JavaScript Alertbox
erzeugt, die eine entsprechende Warnung ausgibt.
In den Dialog zum Auflisten aller Benutzer soll eine Suchfunktion integriert werden. Dazu
muß der Standard-Dialog um die für die Suchfunktion notwendigen Elemente erweitert
werden. Durch diese Änderung ergibt sich der in Abbildung 6.9 dargestellte Dialog.
Abbildung 6.9: Der „Benutzer anzeigen“-Dialog wird um eine Suchfunktion erweitert.
37
Die Implementierung dieser Funktion kann der im Anhang 2 beiliegenden CD
entnommen werden.
82
Kapitel 6: Technischer Entwurf der ausgewählten Variante
83
Der Entwurf des Dialogs zur Auflistung aller Gruppenobjekte erfolgt analog. Das
Suchinterface, um nach Gruppenobjekten zu suchen, erlaubt jedoch nur nach deren
Kennung38 zu suchen, da für Gruppenobjekte weder ein Name-Attribut, noch ein
Abteilung-Attribut definiert ist (siehe auch Kapitel 3.4.1). Der Dialog, um im Rahmen
der hierarchischen Benutzerverwaltung Benutzerobjekte zu Gruppen zuordnen zu können,
wird ebenfalls nach demselben Prinzip entworfen. Dabei ist zu beachten, daß dieser Dialog
sowohl eine Suchfunktion für Benutzer- als auch für Gruppenobjekte zur Verfügung
stellen muß. Um diese Suchfunktionalität anzubieten, werden die beiden Suchinterfaces für
Benutzerobjekte und für Gruppenobjekte in diesem Dialog kombiniert.
Im nächsten Abschnitt wird gezeigt, welche Änderungen in den Wavemaster-Templates
vorgenommen werden müssen, um die hierarchische Benutzerverwaltung in die
Funktionalität eine Hyperwave Information Servers 4.1 einzubinden.
6.5 Behandlung der Requests der
hierarchischen Benutzerverwaltung
Im Rahmen der hierarchischen Benutzerverwaltung können vom Benutzer die in Tabelle
6.4 angeführten Aktionen ausgeführt werden. Jeder dieser Aktionen ist eine eigene Serveraction zugeordnet (siehe auch Kapitel 6.3).
Name der Server-action
auszuführendes Macro
Datei
dialog.ni_newuser.action
NI_dialog_newuser
ni_newuser.hwt
dialog.ni_insertnewuser.action
NI_dialog_insertnewuser
ni_insertnewuser.hwt
dialog.ni_listuser.action
NI_dialog_listuser
ni_listuser.hwt
dialog.ni_deleteuser.action
NI_dialog_deleteuser
ni_deleteuser.hwt
dialog.ni_edituser.action
NI_dialog_edituser
ni_edituser.hwt
dialog.ni_changeuser.action
NI_dialog_changeuser
ni_changeuser.hwt
dialog.ni_newgroup.action
NI_dialog_newgroup
ni_newgroup.hwt
dialog.ni_insertnewgroup.action
NI_dialog_insertnewgroup
ni_insertnewgroup.hwt
dialog.ni_listgroups.action
NI_dialog_listgroups
ni_listgroups.hwt
dialog.ni_deletegroups.action
NI_dialog_deletegroups
ni_deletegroups.hwt
dialog.ni_editgroup.action
NI_dialog_editgroup
ni_editgroup.hwt
38
UGroup-Attribut
Kapitel 6: Technischer Entwurf der ausgewählten Variante
84
dialog.ni_changegroup.action
NI_dialog_changegroup
ni_changegroup.hwt
dialog.ni_showgroupmembers.action
NI_dialog_showgroupmember
s
ni_showgroupmembers.hw
t
dialog.ni_assign_u_g.action
NI_dialog_assign_u_g
ni_assign_u_g.hwt
dialog.ni_add_u_g.action
NI_dialog_add_u_g
ni_add_u_g.hwt
dialog.ni_remove_u_g.action
NI_dialog_remove_u_g
ni remove_u_g.hwt
Tabelle 6.4: Die Server-Actions und dazugehörigen Macros der hierarchischen
Benutzerverwaltung.
Anhand der aufgerufenen Server-action wird in ein entsprechendes Makro verzweigt.
Dieses Makro enthält den SSJS-Code, der zur Ausführung der vom Benutzer gewählten
Aktion notwendig ist. Jedes Makro im Rahmen der hierarchische Benutzerverwaltung
befindet sich in einer eigenen Datei. Der Entwurf des Codes für diese Makros soll nach den
Methoden der Objektorientierten Programmierung erfolgen. Außerdem sollen, die im
Rahmen dieses Projekts entworfenen Objekte in die am IICM entwickelte Objektbibliothek
hwlib eingebunden werden.
Bevor sich diese Arbeit mit dem objektorientierten Entwurf der Funktionalität für die
hierarchische Benutzerverwaltung beschäftigt, soll daher auf objektorientiertes
Programmieren in JavaScript und die Objektbibliothek hwlib eingegangen werden.
6.6 Objektorientiertes Programmieren in
JavaScript
JavaScript ist eine objektorientierte Sprache, die nicht auf dem Klassen-Konzept aufbaut,
sondern auf dem Konzept von Prototypen. Programmiersprachen wie C++ oder Java, die
auf dem Klassen-Konzept aufbauen, basieren auf Klassen und Instanzen. Eine Klasse
definiert alle Eigenschaften, die eine bestimmte Menge von Objekten beschreibt. Eine
Klasse ist nicht ein Mitglied der Menge von Objekten, die durch die Klasse beschrieben
werden, sondern eine Vorschrift, wie solche Objekte gebildet werden. So kann z.B. die
Klasse Employee die Menge aller Angestellten repräsentieren. Im Gegensatz dazu ist eine
Instanz ein konkretes Objekt aus der Menge von Objekten, die durch die Klasse
beschrieben werden. Zum Beispiel kann Victoria eine Instanz der Klasse Employee sein,
die eine bestimmte Person als Angestellte repräsentiert. [JSO99]
In einer auf Prototypen basierenden Programmiersprache, wie JavaScript, wird diese
Unterscheidung zwischen Klassen und Instanzen nicht getroffen, man spricht nur von
Objekten. Eine auf Prototypen basierende Sprache verwendet sogenannte prototypical
Objects als Bildungsvorschrift für neue Objekte. Jedes Objekt kann seine spezifischen
Eigenschaften definieren39, entweder wenn ein Objekt erzeugt wird, oder sogar erst zur
39
Member-Variablen und Methoden
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Laufzeit. Außerdem kann jedes Objekt mit dem Prototyp eines anderen Objekts assoziiert
werden. [JSO99]
In auf Klassen basierenden Sprachen werden Klassen in eigenen Klassen-Definitionen
beschrieben. In diesen Definitionen können spezielle Methoden, sogenannte Konstruktoren
spezifiziert werden, um Instanzen einer Klasse zu erzeugen. Ein Konstruktor kann
Anfangswerte für Membervariablen einer Instanz festlegen und Programmcode ausführen,
der beim Erzeugen einer neuen Instanz durchgeführt werden muß. Diese Konstruktoren
werden in Zusammenhang mit dem new-Opertator verwendet, um neue Instanzen einer
Klasse zu erzeugen. [JSO99]
JavaScript folgt einem ähnlichen Modell, jedoch müssen in JavaScript sogenannte
Konstruktor-Funktionen definiert werden, um neue Objekte erzeugen zu können. Jede in
JavaScript definierte Funktion kann als Konstruktor-Funktion dienen. Die KonstruktorFunktion wird gemeinsam mit dem new-Operator verwendet, um ein neues JavaScriptObjekt zu erzeugen. [JSO99]
In einer auf Klassen basierenden Sprache können Klassen als Subklasse einer bereits
exsitierenden Klasse definiert werden. Die Subklasse erbt alle Eigenschaften der
Superklasse und kann zusätzlich neue Eigenschaften definieren oder geerbte Eigenschaften
modifizieren. Besitzt die Klasse Employee z.B. nur die Membervariablen name und dept
und Manager ist eine Subklasse von Employee, welche die Membervariable reports
hinzufügt, so besitzt eine Instanz der Manager-Klasse alle drei Membervariablen: name,
dept und reports. [JSO99]
JavaScript ermöglicht Vererbung, indem prototypical Objects mit Konstrutor-Funktionen
assoziiert werden können. Auf diese Weise kann auch in JavaScript das zuvor erwähnte
Beispiel umgesetzt werden, jedoch kommt in JavaScript ein anderer Mechanismus zum
Einsatz: Im ersten Schritt wird eine Konstruktor-Funktion für Employee definiert, welche
die Variablen name und dept spezifiziert. Im nächsten Schritt wird die Manager
Konstruktor-Funktion definiert, welche die Variable reports spezifiziert. Im letzten
Schritt wird ein neues Employee-Objekt als der Prototype des Manager-Objekts definiert.
Dann erbt ein Manager-Objekt beim Erzeugen automatisch die Variablen name und dept
vom Employee-Objekt. [JSO99]
In auf Klassen basierenden Sprachen werden Klassen üblicherweise bereist beim
Kompilieren40 des Programmcodes erzeugt. Instanzen einer Klasse können dann entweder
auch bereits beim Kompilieren oder auch erst zur Laufzeit erzeugt werden. Nachdem eine
Klasse definiert wurde, können die Eigenschaften der Klasse nicht mehr verändert werden.
In JavaScript jedoch, können auch zur Laufzeit neue Eigenschaften zu Objekten
hinzugefügt werden, oder entfernt werden. Wird eine neue Eigenschaft einem prototypical
Object hinzugefügt, so bekommen auch alle Objekte für die das entsprechende prototypical
Object der Prototyp ist, diese Eigenschaft zur Laufzeit zugeordnet. [JSO99]
Das folgende Beispiel für objektorientiertes Programmieren unter JavaScript wurde
[JSO99] entnommen. Anhand der Abbildung 6.10 abgebildeten Objekthierarchie soll die
Definition von Objekten unter JavaScript veranschaulicht werden. Um die Beispiele
verständlicher zu machen und die Unterschiede zu auf Klassen basierenden
40
Mit Kompilieren wird das Übersetzen von Programmcode in ausführbaren
Maschinencode bezeichnet.
85
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Programmiersprachen nochmals zu verdeutlichen, werden äquivalente Objektdefinitionen
auch in der Programmiersprache Java gegenübergestellt.
Abbildung 6.10: Anhand dieser einfachen Objekthierarchie soll objektorientiertes
Programmieren unter JavaScript veranschaulicht werden.
Die Definitionen für das Employee-Objekt in JavaScript und Java werden in Tabelle 6.5
gegenübergestellt. Diese beiden Definitionen haben identische Bedeutung. Der einzige
Unterschied ist, daß für jede Memeber-Variable in Java ein Typ angegeben werden muß
und eine explizite Konstruktor-Methode in der Java Klasse definiert werden muß.
JavaScript
Java
function Employee () {
this.name = "";
this.dept = "general";
}
public class Employee {
public String name;
public String dept;
public Employee () {
this.name = "";
this.dept = "general";
}
}
Tabelle 6.5: Das Employee Objekt und die Klasse Employee
Die Definitionen für Manager und WorkerBee in Tabelle 6.6 zeigen die Unterschiede, wie
Superklassen eines Objekts in JavaScript und Java angegeben werden. In JavaScript wird
eine Instanz der Superklasse als Wert der Membervariable prototype in der KonstruktorFunktion angegeben. Diese Zuweisung kann zu jeder Zeit 41 nach der Definition der
Konstruktor-Funktion erfolgen. In Java wird die Superklasse in der Klassendefinition
41
Das bedeutet, prototype kann auch erst während der Laufzeit definiert werden.
86
Kapitel 6: Technischer Entwurf der ausgewählten Variante
87
angegeben und kann, einmal definiert, später nicht mehr verändert werden.
JavaScript
Java
function Manager () {
this.reports = [];
}
Manager.prototype =
new Employee;
public class Manager
extends Employee {
public Employee[] reports;
public Manager () {
this.reports =
new Employee[0];
}
}
function WorkerBee () {
this.projects = [];
}
WorkerBee.prototype =
new Employee;
public class WorkerBee
extends Employee {
public String[] projects;
public WorkerBee () {
this.projects =
new String[0];
}
}
Tabelle 6.6: Manager und WorkerBee werden vom Employee abgeleitet.
Die in Tabelle 6.7 angeführten Definitionen für Engeneer und SalesPerson erzeugen
Objekte, die von WorkerBee ableiten. Diese Definitionen überschreiben den Wert der
vererbten Membervariable dept mit neuen Werten.
JavaScript
Java
function SalesPerson () {
this.dept = "sales";
this.quota = 100;
}
SalesPerson.prototype =
new WorkerBee;
public class SalesPerson
extends WorkerBee {
public double quota;
public SalesPerson () {
this.dept = "sales";
this.quota = 100.0;
}
}
function Engineer () {
this.dept = "engineering";
this.machine = "";
}
Engineer.prototype =
new WorkerBee;
public class Engineer
extends WorkerBee {
public String machine;
public Engineer () {
this.dept = "engineering";
this.machine = "";
}
}
Tabelle 6.7: Die Definitionen für SalesPerson und Engineer.
Diese Definitionen aus Tabelle 6.5 bis Tabelle 6.7 können nun verwendet werden, um neue
Objekte dieser Typen zu erzeugen. Diesen Objekten werden die Anfangswerte ihrer
Membervariablen zugewiesen. Abbildung 6.11 zeigt, wie diese Definitionen verwendet
Kapitel 6: Technischer Entwurf der ausgewählten Variante
werden, um neue Objekte zu erzeugen.
Abbildung 6.11: Nachdem Objekte definiert wurden, können Instanzen dieser Objekte mit
dem new-Operator erzeugt werden.
In diesem Abschnitt wurde genauer auf Objektorientiertes Programmieren unter JavaScript
eingegangen. Im nächsten Kapitel können nun die grundlegenden Eigenschaften der am
IICM entwickelten objektorientierten JavaScript-Bibliothek hwlib untersucht werden, in
die einige Objekte der hierarchischen Benutzerverwaltung eingebunden werden sollen.
6.7 Die JavaScript-Bibliothek hwlib
Die Entwicklung der HyperWave LIBary, kurz hwlib wurde im September 1998
begonnen und wird seitdem von einer Projektgruppe des IICM fortgeführt. Diese
Bibliothek wurde aus folgenden Gründen entwickelt: [Hwl99]

Verbesserung und Beschleunigung des Software-Entwicklungs-Prozesses unter
Hyperwave.

Bessere Qualtäts-Sicherung.

Objektorientierte Entwicklung unter JavaScript (siehe Kapitel 6.6).

Profit durch das Bibliothek-Konzept:
-
Wiederverwendbarkeit
-
Modularität
88
Kapitel 6: Technischer Entwurf der ausgewählten Variante
-
Stabilität
-
Erweiterbarkeit
-
Einfachheit
89
Dieses Kapitel gibt nur eine grobe Übersicht über die wichtigsten Konzepte der Bibliothek
hwlib. Es wird beschrieben, wie die hwlib mit dem Hyperwave Information Server
zusammenarbeitet und wie diese Zusammenarbeit funktioniert. Nachfolgende Absätze
beziehen sich auf [Hwl99].
Das Basisobjekt für alle weiteren Objekte in hwlib ist hw_Object. Dieses Objekt dient als
„Superklasse“ für alle weiteren Objekte in hwlib. Alle Objekte, die der hwlib angehören
besitzen das Prefix „hw_“. Jedes Objekt der hwlib wird in einer eigenen Datei abgelegt,
z.B. wird das Objekt hw_TextObject in der Datei hw_TextObject.js abgelegt.
Abbildung 6.12 zeigt die Objekthierarchie der momentan in hwlib definierten Objekte.
Diese core-Objekte der hwlib liegen in dem Verzeichnis hwlib/objects.
hw_Object
hw_DocumentObject
hw_TextObject
hw_TextObjectHTML
hw_ImageObject
hw_GenericObject
hw_CollectionObject
hw_SequenceObject
hw_ClusterObject
hw_MultiClusterObject
hw_AlternativeClusterObject
hw_QueryObject
Abbildung 6.12: Die Objekthierarchie der in hwlib verfügbaren Objekte
Alle Objekte werden von der Basisklasse hw_Object abgeleitet. Ein hw_Object kann mit
einem Objekt, das sich am Hyperwave Server befindet instanziert werden. Besitzt das
Hyperwave-Objekt den Namen test/test.txt, so kann mit dem in Beispiel 6.1
angeführten Befehl leicht ein äquivalentes hw_Objekt erzeugt werden.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
var testObject = new hw_Object(”test/test.txt”)
Beispiel 6.1: Erzeugen eines neuen hw_Object-Objekts
hw_Object stellt die Basisfunktionalität zur Manipulation und Anzeige von Hyperwave-
Objekten zur Verfügung. Dazu zählen:

10 Attribut-Manipulations-Methoden

20 Attribut-Zugriffs-Methoden

7 Anzeige-Methoden

4 Umwandlungs-Methoden

7 Zugriffs- und Suchmethoden

17 weitere Methoden, wie z.B. holen der Eltern-Objekte, duplizieren, usw.
Diese Methoden können von abgeleiteten Objekten benutzt, überschrieben oder erweitert
werden. Neue Applikationen können dieses Schema verwenden, um weitere applikationsspezifische Objekte von hw_Object abzuleiten.
Um die Bibliothek hwlib in den Hyperwave Information Server einzubinden, müssen zwei
wesentliche Änderungen im Wavemaster-Verzeichnis des entsprechenden Servers
vorgenommen werden: Zum ersten muß die Standard-hwlib in das entsprechende
Wavemaster-Verzeichnis eingefügt werden. Dazu wird das gesamte hwlib-Vezeichnis
unterhalb des Wavemaster-Verzeichnisses kopiert. Besitz das Wavemaster-Verzeichnis
den Namen wavemaster-4.1, so liegt die hwlib im Verzeichnis wavemaster4.1/hwlib. Die zweite Änderung, die vorgenommen werden muß, um die hwlib in den
Hyperwave Server einzubinden, ist die Modifikation des Master-Templates mit dem
Namen wavemaster-4.1/master.html. Diesem Template müssen vier includes
hinzugefügt werden, welche die Objekte und Hilfsfunktionen der hwlib in den Hyperwave
Server einbinden. In der Standard-hwlib steht ein solches modifiziertes Master-Template
bereits unter dem Namen default.master.html.41 zur Verfügung.
Wurden diese beiden Änderungen der Standard-Templates durchgeführt, so kann der
Programmierer die Funktionalität der hwlib-Benutzern, um neue Applikationen unter
Hyperwave zu entwickeln. Die Objekte, die für die hierarchische Benutzerverwaltung
entworfen werden, sollen in hwlib eingebunden werden.
Wie in Abschnitt 6.5 bereits erwähnt wurde, soll der Entwurf der für die Umsetzung einer
hierarchischen Benutzerverwaltung benötigten Funktionalität nach den Methoden des
OOD erfolgen. Im nächsten Abschnitt sollen daher zuerst die Aufgaben des OODs
untersucht werden, bevor in Kapitel 6.9 der objektorientierte Entwurf der für die
hierarchische Benutzerverwaltung benötigten Funktionalität erfolgt.
90
Kapitel 6: Technischer Entwurf der ausgewählten Variante
6.8 Objektorientierte Entwurfsmethodik
Wie die Erfahrung zeigt, ist das Design einer Softwarekomponente weder ein reiner topdown Prozeß, noch ein reiner bottom-up Prozeß. [Pfl98] Komplexe Systeme werden am
besten mit der Methode des round-trip gestalt designs entworfen. „Dieser Begriff
bezeichnet die fortschreitende und sich wiederholende Entwicklung eines Systems durch
die Verfeinerung von verschiedenen aber konsistenten Betrachtungsweisen des Systems als
Ganzes.“42 [Boo92] Der Verfasser der Arbeit, Booch [Boo92], nimmt an, daß round-trip
gestalt design die Grundlage von objektorientiertem Design ist. Der Prozeß des
objektorientierten Designs wird nach Booch in folgende Tätigkeiten unterteilt:

Identifizieren der Klassen und Objekte in einem relativ hohem Abstraktionsgrad

Identifizieren der Aufgaben und Verantwortlichkeiten dieser Klassen und Objekte

Identifizieren der Beziehungen zwischen diesen Klassen und Objekten

Implementierung der Klassen und Objekte
Dieser Prozeß ist ein sich wiederholender Prozeß. Werden neue Klassen und Objekte
gefunden, so beinhaltet dies meist eine Verfeinerung und Verbesserung von bereits
existierenden Klassen und Objekten. Selbst während der Implementierungsphase können
noch neue Klassen und Objekte entdeckt werden, die das bestehende Design vereinfachen
und verbessern. Der objektorientierte Entwurfsprozeß beginnt mit einer Analyse des
Vokabulars, mit dem das Problem beschrieben wurde. Das Ziel ist, durch die Analyse der
Problembeschreibung alle Einheiten zu erkennen, die ein Rolle in der Softwarekomponente
übernehmen sollen, deren Beziehungen untereinander festzulegen, die Funktionen, die
diese Einheiten ausführen, erkennen und diese Einheiten genau zu analysieren, um ihre
Aufgaben genau verstehen zu können. Der Prozeß kann beendet werden, wenn keine neue
Klassen und Objekte mehr gefunden werden können. [Boo92]
Im restlichen Teil dieses Kapitels wird kurz auf die zuvor erwähnten Tätigkeiten
eingegangen, in die der Prozeß des objektorientierten Designs unterteilt wird.
6.8.1 Identifizieren der Klassen und Objekte
Wie in Abschnitt 6.8 bereits erwähnt wurde, wird der Prozeß des objektorientierten
Designs in vier aufeinanderfolgende Tätigkeiten unterteilt. Im ersten Schritt des
Designprozesses hat der Entwickler die folgenden Aufgaben zu lösen: [Boo92]

42
Key Abstractions: Unter dem Begriff „Key Abstaction“ versteht man die Klassen und
Objekte, die im Vokabular der Problemstellung verwendet werden, um das Problem zu
beschreiben. Der Entwickler versucht die Key Abstractions in der Problemstellung zu
erkennen.
This style of design emphasizes the incremental and iterative development of a system
through the refinement of different yet consistent logical and physical views of the system
as a whole. [Boo92]
91
Kapitel 6: Technischer Entwurf der ausgewählten Variante

Mechanisms: Der Entwickler legt die Mechanismen fest, wie Klassen und Objekte
zusammenarbeiten, um das Verhalten zu erreichen, das durch die Problemstellung
gefordert wird.
Währen dieser Entwicklungsphase betrachtet der Entwickler die Key Abstractions und
Mechanisms von außen. Seine Aufgabe ist, das logische Grundgebilde (die Klassen und
Objekte) des Systems zu beschreiben. Detaillierte Analysen einzelner Klassen und
Klasseneigenschaften werden in diesem Schritt noch nicht vorgenommen. In den späten
Phasen des Designprozesses ändert sich die Sichtweise des Entwicklers: Seine
Aufmerksamkeit gilt nun dem Innenleben und Implementierungsdetails der einzelnen
Klassen und Objekte. Die Klassen und Objekte, die in diesem Schritt gefunden werden,
stellen nur Kandidaten für tatsächliche Klassen und Objekte dar. Während der späteren
Entwicklungsphasen kann sich durchaus herausstellen, daß zwei Kandidaten in
Wirklichkeit das selbe Objekt bezeichnen, daß ein Kandidat nur eine Membervariable
eines anderen Kandidaten ist, usw. [Boo92]
Eine beliebte und sehr einfache Methode für das Finden von Key Abstractions ist das
Ableiten der Key Abstractions aus einer Beschreibung des Problems. Dabei wird das
Problem (oder ein Teil des Problems) durch eine nicht formale Beschreibung
wiedergegeben. Danach werden alle Hauptwörter mit einer Farbe, alle Zeitwörter mit einer
anderen Farbe unterstrichen. Die Hauptwörter repräsentieren Kandidaten für Objekte, die
Zeitwörter sind Kandidaten für Operationen, die mit und von diesen Objekten ausgeführt
werden. Diese Methode ist nützlich, weil sie sehr einfach ist. Man muß sich aber bewußt
sein, daß die menschliche Sprache ein sehr unpräzises Werkzeug ist, die Qualität der
gefundenen Objekte und Operationen hängt daher sehr von den Fähigkeiten des Autors der
Problembeschreibung ab. [Boo92]
6.8.2 Identifizieren der Verantwortlichkeiten
Im zweiten Schritt versucht der Entwickler die Aufgaben und Verantwortlichkeiten der
einzelnen Objekte zu erkennen. Der Entwickler betrachtet die Klassen und Objekte aus der
Perspektive ihrer Schnittstelle zu Außenwelt. So kann er festlegen, welche Operationen mit
einem Objekt ausgeführt werden können. Dieser Schritt ist um einiges schwieriger als der
erste Schritt und benötigt auch erheblich mehr Zeit. An diesem Punkt wird der
Entwurfsprozeß tatsächlich iterativ. Die Veränderung der Schnittstelle eines bestimmten
Objekts kann dazu führen, daß dadurch auch die Bedeutung eines anderen Objekts
verändert wird. Die Existenz der Key Abstractions geht aber nicht verloren, es werden nur
deren Abgrenzungen verschoben. [Boo92]
6.8.3 Identifizieren der Beziehungen
Der dritte Schritt ist genaugenommen eine Erweiterung des zweiten Schritts. Hier wird
genau festgelegt, wie bestimmte Objekte innerhalb des System zusammenarbeiten. Unter
Berücksichtigung der Key Abstractions werden die Benutzung, Vererbung und andere
Arten von Beziehungen zwischen den Objekten festgelegt. Dieser Schritt besteht im
Wesentlichen aus zwei Aktivitäten: Erstens müssen Muster gesucht werden, durch deren
Hilfe die Klassenstrukur des Systems vereinfacht werden kann. Zweitens, müssen die
92
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Sichtbarkeiten zwischen den Klassen festgelegt werden. Die entscheidende Frage dabei ist,
welche Klassen für andere Klassen sichtbar sind und welche nicht. Während diesem Schritt
kann es durchaus erforderlich werden, Klassendefinitionen aus vorhergehenden SChritten
nochmals zu überdenken oder zu verfeinern. [Boo92] Eine Methode, die in diesem Schritt
eingesetzt werden kann, sind die sogenannten CRC-Karten [CRC99].CRC-Karten sind
einfache Karteikarten. Für jede Klasse in dem System wird eine eigene CRC-Karte
reserviert. Auf jede Karte wird
der Name der entsprechende Klasse, ihr Verhalten und die Klassen, mit denen die
entsprechende Klasse zusammenarbeitet geschrieben. Durch die Simulation bestimmter
Abläufe im System können die Karten verwendet werden, um das Verhalten der Klassen
zu verfeinern.
6.8.4
Implementierung der Klassen und Objekte
Erst in diesem Schritt spezialisiert sich der Entwickler auf das Innenleben der Klassen. Die
Aufgabe dieses Schritts ist es zu entscheiden, wie die einzelnen Methoden und Klassen
implementiert werden sollen. Außerdem ist es Aufgabe dieses Schrittes, die einzelnen
Klassen und Objekte zu Modulen (Bibliotheken) zusammenzufassen. In diesem Schritt des
Entwurf-Prozesses wird das konkrete Interface jeder Klasse zur Außenwelt entworfen.
[Boo92]
Nachdem in den Abschnitten 6.8.1 bis 6.8.4 ein kurzer Überblick auf die objektorientierte
Entwurfsmethodik gegeben wurde, sollen im nächsten Abschnitt der Entwurf der Objekte
für ein System zur hierarchische Benutzerverwaltung unter Hyperwave vorgenommen
werden.
6.9 Objektorientierter Entwurf
Im folgenden Abschnitt soll der Entwurf der Objekte im Rahmen der hierarchischen
Benutzerverwaltung nach der in Kapitel 6.8 beschriebenen Methode erfolgen. Im ersten
Schritt sollen nach Abschnitt 6.9.1 jene Klassen identifiziert werden, die im Rahmen der
hierarchischen Benutzerverwaltung umgesetzt werden müssen.
6.9.1
Identifizieren der Klassen und Objekte
Die zentralen Klasse der hierarchischen Benutzerverwaltung sind eine Benutzerklasse und
eine Gruppenklasse, welche die benötigten Methoden zum Anlegen, Ändern und Löschen
von Benutzer- und Gruppenobjekten am Server im Rahmen der hierarchischen
Benutzerverwaltung bereitstellen. Außerdem müssen im Rahmen der hierarchischen
Benutzerverwaltung Objekte umgesetzt werden, welche die Darstellung der Dialoge, die
für die hierarchischen Benutzerverwaltung benötigt werden, implementieren. Ein weitere
Klasse, die im Rahmen der hierarchischen Benutzerberwaltung benötigt wird, ist ein
spezielles Server-Objekt, das eine Instanz eines HW_API_Servers beinhaltet und diesen
verwaltet. Diese Klasse soll auch speziellen Funktionen bereitstellen, die zum Lesen,
93
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Suchen und Manipulieren der Benutzer- und Gruppenobjekte im Rahmen der
hierarchischen Benutzerverwaltung benötigt werden.
Außer diesen Objekten, die direkt aus den Anforderungen an eine hierarchische
Benutzerverwaltung abgeleitet werden können, sollen zwei weitere Objekte in das System
zur hierarchischen Benutzerverwaltung eingebunden werden, welche die Fehlersuche und
Fehlerbehandlung unter JavaScript ermöglichen. Um in der Testphase die Fehlersuche in
den SSJS-Scripts zu erleichtern, soll ein Logfile-Objekt zur Fehlersuche in den Scripts
vorgesehen werden. Aufgabe des Logfile-Objekts ist, verschiedene Möglichkeiten zur
Verfügung zu stellen, um Debug-Output in eine Datei zu schreiben. Tritt während des
Ablauf eines Scripts ein Fehler auf, so muß das Script entsprechend darauf reagieren
können und eine Fehlermeldung an den Client zurücksenden. Daher soll neben dem
Logfile-Objekt auch ein Error-Objekt in die SSJS-Scripts aufgenommen werden. Das
Error-Objekt unterstützt die Behandlung von Fehlern, die während des Ablauf eines Scripts
auftreten können. Besonders ist das Error-Objekt zur Behandlung solcher Fehler
vorgesehen, die durch fehlgeschlagene Zugriffe des Scripts auf den Server auftreten. Zwei
Objekte, welche die Funktionalität zur Fehlersuche und Fehlerbehandlung umsetzen,
werden von der Objektbibliothek hwlib bereits angeboten. Es sie in diesem
Zusammenhang auf [HWL99] verwiesen.
Nachdem in diesem Schritt die Klassen und Objekte für ein System zur hierarchischen
Benutzerverwaltung identifiziert wurden, sollen nun im nächsten Schritt nach der in
Kapitel 6.8 festgelegten Vorgehensweise die Verantwortlichkeiten und Aufgaben dieser
Objekte genauer untersucht werden.
6.9.2
Identifizieren der Verantwortlichkeiten
Ziel dieses Abschnitts ist, die genauen Aufgaben und Verantwortlichkeiten der einzelnen
Objekte, die im vorigen Schritt identifiziert wurden, festzulegen. In einem ersten Schritt
sollen die Aufgaben des Benutzerobjekts genauer untersucht werden.
Das Benutzerobjekt
Die Aufgabe des Benutzerobjekts ist es, Methoden bereitzustellen, um die Verwaltung von
Benutzern am Server im Rahmen der hierarchischen Benutzerverwaltung vornehmen zu
können. Dazu zählen neben den Methoden zum Anlegen, Ändern und Löschen von
Benutzern auch Methoden, um die benötigten Dialoge für die hierarchische
Benutzerverwaltung am Client anzeigen zu können. Der Entwurf des Benutzerobjekts soll
in zwei Schritten erfolgen.
Im ersten Schritt wird eine Objekt entworfen, die allgemeine und wiederverwendbare
Methoden zur Verwaltung von Benutzerobjekten am Server bereitstellt. Die speziellen
Anforderungen der hierarchischen Benutzerverwaltung an das Benutzerobjekt werden in
diesem Schritt noch nicht berücksichtigt. Dadurch entsteht eine wiederverwendbares
Objekt, die in die hwlib eingebunden werden kann. Dieses Objekt leitet von der
Basisklasse der hwlib, dem hw_Object ab und wird mit dem Namen hw_UserObject
bezeichnet.
94
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Im zweiten Schritt wird das Objekt zur Darstellung der Dialoge zum Erzeugen, editieren
und Löschen von Benutzerobjekten entworfen. Um diese Aufgabe erfüllen zu können, wird
dieses Objekt mit dem Namen hw_UserObjectDecorator von hw_UserObject ableiten.
Das Objekt hw_userObject muß einige Methoden seiner Superklasse mit neuer
Funktionalität überschreiben Tabelle 6.8 zeigt alle Methoden, die von hw_UserObject mir
neuer Funktionalität überschrieben werden müssen.
Methodenname
Funktion
displayObject()
darstellen der Attribute des Benutzerobjekts
getParents()
Gruppen, denen Benutzer zugeordnet ist
remove()
Benutzer löschen
insert()
neuen Benutzer einfügen
Tabelle 6.8: Methoden, die von hw_UserObject überschrieben werden.
Zusätzlich zu diesen Methoden besitzt das hw_UserObject auch neue Methoden. Tabelle
6.9 zeigt eine Auflistung dieser Methoden.
Methodenname
Funktion
assignToGroups()
Benutzer zu Gruppen zuweisen
removeFromGroups()
Benutzer aus Gruppen löschen
inGroup()
true, falls Benutzer Gruppe angehört
Tabelle 6.9: Neue Methoden des hw_UserObjects
Eine genaue Erklärung der Funktionalität und Parameter dieser Methoden erfolgt in
Kapitel 6.9.4. Im zweiten Schritt wird von dem hw_UserObject eine Klasse abgeleitet,
welche die speziell für die hierarchische Benutzerverwaltung benötigten Methoden zur
Visualisierung der Benutzerdialoge im Rahmen der hierarchischen Benutzerverwaltung
bereitstellt. Diese Klasse wird mit dem Namen hw_UserObjectDecorator bezeichnet.
Die Klasse hw_UserObjectDecorator wird nicht in die hwlib eingebunden. Tabelle
6.10 zeigt eine Auflistung der Methoden, welche die Klasse hw_UserObjectDecorator
umsetzt.
95
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Methodenname
Funktion
showNewUserDlg()
Dialog zum Anlegen eines neuen Benutzers
showChangeAttrDlg()
Dialog zum Ändern von Benutzerdaten
showListUsersDlg()
Dialog, der alle Benutzer auflistet
Tabelle 6.10: Die Klasse hw_UserObjectDecorator implementiert die Funktionen zum
Anzeigen der Dialoge
Es sei an dieser Stelle angemerkt, daß eine genaue Beschreibung der Funktionalität und
Parameter der Methoden von hw_UserObjectDecorator in Kapitel 6.9.4 erfolgt.
Das Gruppenobjekt
Das zweite zentrale Objekt, das für die hierarchischen Benutzerverwaltung benötigte
Funktionalität bereitstellen soll, ist ein Gruppenobjekt. Dieses Objekt stellt alle Methoden
für die Verwaltung von Gruppenobjekten am Server im Rahmen der hierarchischen
Benutzerverwaltung zur Verfügung. Die Entwicklung des Gruppenobjekts erfolgt analog
zur Entwicklung des Benutzerobjekts in zwei Schritten: Im ersten Schritt wird ein Objekt
von dem Basisobjekt der hwlib, dem hw_Object abgeleitet, das die Basisfunktionen für
Objekte implementiert. Dieses Objekt trägt den Namen hw_GroupObject und wird in die
hwlib eingebunden. Im zweiten Schritt wird ein Objekt implementiert, welches die
speziellen, für die hierarchische Benutzerverwaltung benötigten Methoden zur
Visualisierung der Dialoge zur Gruppenverwaltung umsetzt. Dieses Objekt wird mit dem
Namen hw_GroupObjectDecorator bezeichnet.
Das Objekt hw_GroupObject, muß analog zu dem Objekt hw_UserObject, einige
Funktionen des Basisobjekts hw_Object mit neuer Funktionalität überschreiben. Tabelle
6.11 zeigt eine Auflistung dieser Methoden.
Methodenname
Funktion
displayObject()
darstellen der Attribute des Benutzerobjekts
getParents()
Gruppen, denen Benutzer zugeordnet ist
remove()
Benutzer löschen
insert()
neuen Benutzer einfügen
Tabelle 6.11: Methoden, die von hw_GroupObject überschrieben werden.
Zusätzlich zu diesen Methoden besitzt hw_GroupObject auch neue Methoden Tabelle
6.12 zeigt eine Auflistung dieser Methoden.
96
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Methodenname
Funktion
assignToGroups()
Gruppe zu anderen Gruppen zuweisen
removeFromGroups()
Gruppe aus anderen Gruppen löschen
inGroup()
true, falls Gruppe anderer Gruppe angehört
Tabelle 6.12: Neue Methoden des hw_GroupObjects
Eine genaue Erklärung der Funktionalität und Parameter dieser Methoden erfolgt in
Kapitel 6.9.4. Im zweiten Schritt wird von hw_GroupObject analog zu hw_UserObject,
eine Klasse abgeleitet, welche die speziell für die hierarchische Benutzerverwaltung
benötigten
Methoden
umsetzt.
Diese
Klasse
wird
mit
dem
Namen
hw_GroupObjectDecorator bezeichnet. Die Klasse hw_GroupObjectDecorator wird
nicht in die hwlib eingebunden. Tabelle 6.10 zeigt eine Auflistung der Methoden, welche
die Klasse hw_GroupObjectDecorator umsetzt.
Methodenname
Funktion
showNewUserDlg()
Dialog zum Anlegen eines neuen Benutzers
showChangeAttrDlg()
Dialog zum Ändern von Benutzerdaten
showListUsersDlg()
Dialog, der alle Benutzer auflistet
Tabelle 6.13: Die Klasse hw_GroupObjectDecorator implementiert die Funktionen zum
Anzeigen der Dialoge. Eine genaue Beschreibung dieser Methoden erfolgt in Kapitel 6.9.4.
Redesign des Benutzer & des Gruppenobjekts
Wie die Tabelle 6.8 bis Tabelle 6.12 zeigen, müssen die Objekte hw_UserObject und
hw_GroupObject zum größten Teil dieselbe Funktionalität umsetzen:

hw_Object.displayObject,
hw_Object.getParents, hw_Object.remove, hw_Object.insert mit neuer
Beide
Objekte
müssen
die
Methoden
Funktionalität überschreiben.

Beide Objekte müssen die neuen Methoden assignToGroups, removeFromGroups
und inGroup definieren.
Die Funktionalität dieser Methoden des hw_UserObjects und des hw_GroupObjects
sind, bis auf eine Methode identisch. Aus diesem Grund soll die gemeinsam Funktionalität
von hw_UserObject und hw_GroupObject in ein neues Objekt verschoben werden.
Diese Objekt hat den Namen hw_UserManagementObject und implementiert die den
beiden Objekten gemeinsame Funktionen. Diese Änderung führt dazu, daß
97
Kapitel 6: Technischer Entwurf der ausgewählten Variante
hw_GroupObject und hw_UserObject nicht mehr von hw_Object ableiten, sondern von
dem Objekt hw_UserManagementObject.
Das Server-Objekt
Ein weiteres wichtiges Objekt im Rahmen der hierarchischen Benutzerverwaltung ist ein
Objekt, das den Zugriff auf den Hyperwave Server ermöglicht. Dieses Objekt wird mit
dem Namen hs_lib_Server43 bezeichnet und soll eine Instanz des HW_API_Server
Objektes verwalten und den Zugriff darauf ermöglichen. Neben Funktionen, um diese
Instanz des HW_API_Servers zu verwalten, soll die Server-Klasse eine Reihe spezieller
Funktionen bereitstellen, die es im Rahmen der hierarchischen Benutzerverwaltung
ermöglichen, Benutzer- und Gruppenobjekte anhand ihres Informationsraum-Attributes zu
Suchen, zu Lesen und zu Modifizieren. Die SSJS-Scripts, welche die Aufgaben der
hierarchischen Benutzerverwaltung durchführen sollen, müssen mit Systemrechten auf den
Server zugreifen dürfen. Um diesen Zugriff zu ermöglichen, muß eine Anmeldung am
Server mit Systemrechten erfolgen. Die Login Kennung und das Paßwort für diese
Anmeldung müssen aus Sicherheitsgründen außerhalb des Wavemaster-Verzeichnisses
abgelegt werden, da sie sonst mit einem Trick von jedem Benutzer ausgelesen werden
könnten44. Daher werden das Paßwort und die Login Kennung nicht direkt in der ServerKlasse, die innerhalb des Wavemaster-Verzeichnisses liegen muß, gespeichert, sondern in
einer eigene Datei, die außerhalb des Wavemaster-Verzeichnisses liegt. Die Server-Klasse
muß auch eine Methode zur Verfügung stellen, um diese Datei auszulesen und eine
Anmeldung am Server mit dem darin gespeicherten Benutzername und Paßwort
durchzuführen.
Zusammenfassend stellt die Server-Klasse die in Tabelle 6.14 aufgelisteten Funktionen zur
Verfügung:
Methode
Beschreibung
getServerName
Name des aktuellen Servers
getServerPort
HG-CSP Port des aktuellen Servers
readSystemUserAndPwd
Lesen des Benutzers von File
identify
anmelden am Server
getSystemGroups
alle System-Gruppen
43
Das Objekt hs_lib_Server soll nicht in die hwlib eingebunden werden. Daher folgt
die Benennung dieses Objekts auch nicht dem Bezeichnungsschema der hwlib. (siehe
auch Kapitel 6.7)
44
Mit wavemaster.internal kann direkt auf Dateien innerhalb des WavemasterVerzeichnisses zugegriffen werden. So liest zum Beispiel die URL
http://www.hwtest.at/wavemaster.internal/master.html die Datei master.html des
Hyperwave Servers www.hwtest.at aus.
98
Kapitel 6: Technischer Entwurf der ausgewählten Variante
99
getNosystemGroups
alle Gruppen außer den System-Gruppen
isSystemUser
true, falls der Benutzer Systemrechte hat
isSystemGroup
true, falls Gruppe eine Systemgruppe ist
getGroupsByIS
Gruppen, die bestimmten IS haben
getAllUsersWithIS
Alle Benutzer mit nichtleerem IS
removeSystemGroups
lösche Systemgruppen aus Gruppen-Array
Tabelle 6.14: Methoden der Server-Klasse
Dieses speziell für die hierarchische Benutzerverwaltung entwickelte Objekt leitet nicht
von hw_Object ab und wird aufgrund seiner sehr spezialisierten Funktionalität auch nicht
in hwlib eingebunden. Eine genaue Beschreibung der Methoden dieser Klasse erfolgt in
Kapitel 6.9.4
Nachdem nun die Aufgaben der einzelnen Klassen festgelegt wurden, sollen im nächsten
Schritt die Beziehungen zwischen den einzelnen Klassen festgelegt werden.
6.9.3
Identifizieren der Beziehungen
Aufgabe dieses Abschnittes ist es, die Beziehungen der Objekte untereinander festzulegen.
Abbildung 6.13 zeigt die Vererbungshierarchie der Objekte die für ein System zur
hierarchischen Benutzerverwaltung benötigt werden. Da die Objekte, wie bereits erwähnt,
zum Teil in die Objektbibliothek hwlib eingebunden werden sollen, müssen diese von
dem Basisobjekt der hwlib, dem hw_Object abgeleitet werden.
hw_GroupObjectDecorator
hs_lib_Server werden nicht in die Objektbibliothek hwlib eingebunden.
Die
Objekte
hw_UserObjectDecorator,
und
Kapitel 6: Technischer Entwurf der ausgewählten Variante
100
hwlib
hw_Object
hw_UserManagementObject
hw_UserObject
hw_UserObjectDecorator
hw_GroupObject
hw_GroupObjectDecorator
hs_lib_Server
Abbildung 6.13: Die Objekthierarchie im Überblick
6.9.4
Implementierung der Objekte
In diesem Abschnitt soll die Implementierung der in Kapitel 6.9.1 entworfenen Objekte zur
Umsetzung einer hierarchischen Benutzerverwaltung unter Hyperwave detailliert
ausgearbeitet werden. Dazu müssen vor allem die genaue Funktionalität der Methoden
dieser Objekte und die an diese Methoden zu übergebenden Parameter festgelegt werden.
Im ersten Schritt soll auf auf das Objekt hw_UserManagementObject eingegangen
werden.
hw_UserManagementObject
erzeugt mit:
Objekte dieses Typs werden vom Anwender nicht erzeugt! ( In Java oder
C++ wäre diese Klasse eine abstrakte Superklasse für hw_UserObject
und hw_GroupObject).
Properties:
keine
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Methoden:
Methode
Beschreibung
parents
bestimmt alle Parent-Gruppen
assignToGroups
Weist Objekt Gruppen zu
removeFromGroups
Löscht Objekt aus Gruppen
inGroup
Bestimmt, ob Objekt Gruppe angehört
remove
Löscht Objekt
Tabelle 6.15: Methoden von hw_UserManagementObject
parents
Syntax:
parents()
Parameters:
keine.
Returns:
Array aus Gruppennamen (UGroup-Values)
Beschreibung: Bestimmt UGroup-Values aller Gruppen, denen Benutzer oder Gruppe
zugehört. Die Gruppen werden rekursiv bestimmt! Das bedeutet, falls die
Gruppe A2 die Elterngruppe A1 besitzt und der Benutzer X der Gruppe A2
angehört, so liefert X.parents() „A1“ und „A2“ als Ergebnis.
Beispiele:
var user = new hw_UserObject(“hschwarz“);
var parents = user.parents();
assignToGroups
Syntax:
assignToGroups(groups)
Parameters:
groups: Array von Gruppennamen jener Gruppen, denen der Benutzer
bzw. die Gruppe zugewiesen werden soll.
Returns:
true, falls Funktion ohne Fehler ausgeführt werden konnte. Sonst false.
Beschreibung: Weist dem Benutzer bzw. der Gruppe neue Gruppen zu. Neue Gruppen
werden zu den bereits existierenden Gruppen hinzugefügt (anhängen, kein
überschreiben). Bevor dem hw_Objekt neue Gruppen zugewiesen werden,
wird überprüft, ob diese tatsächlich am Server existieren. Existiert eine
Gruppe nicht, so beendet die Funktion mit einem Fehler. ACHTUNG! Um
mit dieser Funktion durchgeführte Änderungen von Objekten auf den
Server zu übertragen, muß die Methode flush()benutzt werden.
Beispiele:
var user = new hw_UserObject(“hschwarz“);
User.assignToGroups(new Array(“system“));
101
Kapitel 6: Technischer Entwurf der ausgewählten Variante
removeFromGroups
Syntax:
removeFromGroups(groups)
Parameters:
groups: Array von Gruppennamen jener Gruppen, aus denen der Benutzer
bzw. die Gruppe gelöscht werden soll.
Returns:
true, falls Funktion ohne Fehler ausgeführt werden konnte. Sonst false.
Beschreibung: Löscht Gruppen aus dem Objekt. UGroup-Values, zu denen es keine
Gruppe am Server gibt werden ignoriert. ACHTUNG! Um mit dieser
Funktion durchgeführte Änderungen von Objekten auf den Server zu
übertragen, muß die Methode flush()benutzt werden.
Beispiele:
var user = new hw_UserObject(“hschwarz“);
User.removeFromGroups(new Array(“system“));
inGroup
Syntax:
inGroup(groupname)
Parameter:
groupname: Gruppenname, für den die Überprüfung vorgenommen
werden soll.
Returns:
true, falls der Benutzer bzw. die Gruppe der gesuchten Gruppe angehört.
Sonst false.
Beschreibung: Bestimmt, ob sich Objekt in der angegebenen Gruppe befindet.
Beispiele:
var user = new hw_UserObject(“hschwarz“);
if (user.inGroup(“system“))
writeln(“Benutzer hat Systemrechte!“);
remove
Syntax
remove()
Parameter:
keine
Returns:
true, falls Objekt erfolgreich vom Server gelöscht wurde. Sonst false.
Beschreibung: Löscht das entsprechende Objekt vom Hyperwave Server. Das
hw_UserObject selbst wird ebenfalls ungültig und kann nicht mehr
weiterverwendet werden. Falls während des Löschvorganges ein Fehler
auftritt, wird eine entsprechende Fehlermeldung am Error-Objekt
abgelegt.
Beispiele:
var user = new hw_UserObject(“hschwarz“);
user.delete();
hw_UserObject
erzeugt mit:
hw_UserObject constructor:
new hw_UserObject(parameter)
102
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Parameters:
Wird kein Parameter angegeben, so wird ein leeres hw_UserObject
erzeugt. Es erfolgt kein Zugriff auf den Hyperwave Server.
Ist der Parameter vom Typ String (typeof(param) == string), so wird
der Parameter als Uname-Attribut eines Benutzerobjekts interpretiert. Es
erfolgt ein Zugriff auf den Server, um die Attribute des entsprechenden
Benutzerobjekts zu lesen und das hw_UserObject damit zu instanzieren.
Falls das entsprechende Benutzerobjekt am Server nicht gefunden werden
kann, wird ein leeres hw_UserObject erzeugt.
Wird als Parameter ein HW_API_Object übergeben, so wird überprüft, ob
dieses HW_API_Object vom Typ „Benutzer“ ist. Ist dies der Fall, so wird
das hw_UserObject mit den Daten dieses HW_API_Objects instanziert.
Falls das HW_API_Object nicht vom Typ „Benutzer“ ist, wird ein leeres
hw_UserObject erzeugt.
Beschreibung: Die Klasse hw_UserObject erweitert hw_UserManagementObject um
einen Constructor und eine insert-Methode, die es ermöglichen Objekte
des Typs „Benutzer“ am Server anzulegen. Die weitere Funktionalität, die
es ermöglicht Benutzerobjekte zu modifizieren und zu löschen, wird von
dem Objekt hw_UserManagementObject geerbt.
Properties:
keine
Methoden:
Methode
insert
Beschreibung
Fügt einen neuen Benutzer am Server ein
Tabelle 6.16: Methoden von hw_UserObject
insert
Syntax:
insert(user, pwd)
Parameter:
user: Login(UName-Attribut) des einzufügenden Benutzers
pwd: Paßwort des einzufügenden Benutzers, bereits verschlüsselt.
Returns:
true, falls die insert-Funktion erfolgreich abgeschlossen wurde. Sonst
false.
Beschreibung: Fügt ein neues hw_UserObject mit allen Attributen am Server ein. Ein
neuer Benutzer, der am Server eingefügt werden soll, muß zumindest ein
Login und ein dazugehöriges Paßwort besitzen. Daher werden diese beiden
Attribute der Funktion insert direkt als Parameter übergeben. Sind diese
beiden Attribute bereits gesetzt, werden sie von den als Parameter
übergebenen Werten überschrieben. Weitere Attribute können zuvor oder
danach mit den Funktionen zur Attributmanipulation (z.B.
insertAttributeValues) erzeugt und eingefügt werden.
Beispiele:
var user = new hw_UserObject();
user.insertAttributeValues(“Key“,[“Value1“,“Value2“]);
user.insert(“Login“,crypt(“Passwd“));
103
Kapitel 6: Technischer Entwurf der ausgewählten Variante
var user = new hw_UserObject();
user.insert(“Login“,crypt(“Passwd“));
user.insertAttributeValues(“Key“,[“Value1“,“Value2“]);
user.flush();
Im 2. Beispiel muß die flush()-Funktion angewendet werden, um die
Änderungen auf den Server zu übertragen. Im ersten Beispiel muß die
Methode flush() nicht verwendet werden, da durch die Methode
insertAttributeValues() kein bereits am Server bestehendes Objekt
manipuliert wird (Das Objekt existiert auf dem Server erst nach dem
insert()-Befehl).
hw_GroupObject
erzeugt mit:
hw_GroupObject constructor:
new hw_GroupObject(parameter)
Parameters:
Wird kein Parameter angegeben, so wird ein leeres hw_GroupObject
erzeugt. Es erfolgt kein Zugriff auf den Hyperwave Server.
Ist der Parameter vom Typ String ( typeof(param) == string ), so
wird der Parameter als UGroup-Attribut eines Gruppenobjekts interpretiert.
Es erfolgt ein Zugriff auf den Server, um die Attribute der entsprechenden
Gruppe zu lesen und das hw_GroupObject damit zu instanzieren. Falls
das entsprechende Gruppenobjekt am Server nicht gefunden werden kann,
wird ein leeres hw_GroupObject erzeugt.
Wird als Parameter ein HW_API_Object übergeben, so wird überprüft, ob
dieses HW_API_Object vom Typ „Gruppe“ ist. Ist dies der Fall, so wird
das hw_GroupObject mit den Daten dieses HW_API_Objects instanziert.
Falls das HW_API_Object nicht vom Typ „Gruppe“ ist, wird ein leeres
hw_GroupObject erzeugt.
Beschreibung: Die Klasse hw_GroupObject erweitert hw_UserManagementObject mit
einem Constructor und einer insert-Methode, die es ermöglichen
Objekte des Typs “Gruppe“ am Server anzulegen. Die weitere
Funktionalität, die es ermöglicht Gruppenobjekte zu modifizieren und zu
löschen, wird von hw_UserManagementObject geerbt.
Properties:
keine
Methoden:
Methode
insert
Beschreibung
Fügt neue Gruppe am Server ein
Tabelle 6.17: Methoden des hw_GroupObject
104
Kapitel 6: Technischer Entwurf der ausgewählten Variante
insert
Syntax:
insert(user)
Parameter:
user: Login(UGroup-Value) der einzufügenden Gruppe
Returns:
true, falls die insert-Funktion erfolgreich abgeschlossen wurde. Sonst
false.
Beschreibung: Fügt das neue hw_GroupObject mit allen Attributen am Server ein. Eine
neue Gruppe, die am Server eingefügt werden soll, muß zumindest ein
UGroup-Attribut besitzen. Daher wird dieses Attribut der Funktion insert
direkt als Parameter übergeben. Ist dieses Attribut bereits gesetzt, wird es
von dem als Parameter übergebenen Werten überschrieben. Weitere
Attribute können zuvor oder danach mit den Funktionen zur
Attributmanipulation (z.B. insertAttributeValues) erzeugt und
eingefügt werden.
Beispiele:
var group = new hw_GroupObject();
group.insertAttributeValues(“Key“,[“Value1“,“Value2“]);
group.insert(“Test1“);
var group = new hw_GroupObject();
group.insert(“Test2“);
group.insertAttributeValues(“Key“,[“Value1“,“Value2“]);
group.flush();
hs_lib_Server
erzeugt mit:
hs_lib_Server constructor:
new hs_lib_Server(parameter)
Parameter:
Wird kein Parameter angegeben, so wird ein leeres hs_lib_ServerObjekt erzeugt. Es kann kein Zugriff auf den Hyperwave Server erfolgen.
Als Parameter kann optional der Name einer Datei im Filesystem
angegeben werden, die Benutzernamen und Paßwort des Benutzers enthält,
mit denen sich das hs_lib_Server-Objekt auf den Server anmelden
soll. Diese Datei enthält Login-Kennung und Paßwort in einer Zeile in
dem Format <login> <password>
Beschreibung: Die Klasse hs_lib_Server referenziert ein HW_API_Server-Objekt und
stellt Methoden zur Verfügung, um dieses Serverobjekt zu verwalten
(identify, getPort, getHost). Die zweite Funktionsgruppe umfaßt
Funktionen, die im Rahmen der hierarchischen Benutzerverwaltung
angeboten werden müssen, um spezielle Abfragen des InformationsraumAttributes von Benutzer- und Gruppenobjekten durchzuführen.
Properties:
this.server: Referenz auf den aktuellen HW_API_Server
105
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Methoden:
Methode
Beschreibung
getServerName
Name des aktuellen Servers
getServerPort
HG-CSP Port des aktuellen Servers
readSystemUserAndPwd
Lesen des Benutzers von File
identify
anmelden am Server
getSystemGroups
alle Systemgruppen
getNosystemGroups
alle nicht- Systemgruppen
isSystemUser
true, falls Benutzer Systemrechte hat
isSystemGroup
true, falls Gruppe Systemgruppe ist
getGroupsByIS
Gruppen, die bestimmten IS haben
getAllUsersWithIS
Alle Benutzer mit nichtleerem
Informationsraum-Attribut
removeSystemGroups
lösche Systemgruppen
Tabelle 6.18: Methoden des hs_lib_Server-Objekts
getServerName
Syntax:
getServerName()
Parameters:
keine.
Returns:
Name des aktuellen Servers.
Beschreibung: Diese Funktion gibt den Namen des Servers zurück, auf dem diese
Funktion aufgerufen wurde.
Beispiele:
var server_object = new hs_lib_Server();
var server_name = server_object.getServerName();
getServerPort
Syntax:
getServerPort()
Parameters:
keine.
Returns:
Portnummer des aktuellen Wavemasters.
Beschreibung: Diese Funktion gibt die Nummer des Ports zurück, auf dem der
Wavemaster mit dem Server (Session-Layer) kommuniziert (siehe auch
Kapitel 4.5).
Beispiele:
var server_object = new hs_lib_Server();
var server_port = server_object.getServerPort();
106
Kapitel 6: Technischer Entwurf der ausgewählten Variante
107
readSystemUserAndPwd
Syntax:
readSystemUserAndPwd(file_name)
Parameter:
file_name: gibt Namen der Datei an, aus dem Login-Kennung und
Paßwort gelesen werden sollen.
Returns:
Ein Objekt, das die Membervariablen user und passwd besitzt.
Beschreibung: Die Membervariablen des zurückgelieferten Objekts enthalten den
ausgelesenen Benutzernamen und das dazugehörige Paßwort. Die Datei, in
dem Login und Benutzername gespeichert werden, sollte außerhalb des
Wavemaster-Verzeichnisses liegen. Diese Datei enthält in der ersten Zeile
zuerst den Benutzernamen und dann das Paßwort, durch ein einzelnes
Leerzeichen voneinander getrennt. Falls Benutzername und Paßwort nicht
gelesen werden können, liefert die Methode den Wert false zurück.
Außerdem wird eine entsprechende Fehlermeldung am Error-Objekt
abgelegt.
Beispiele:
var server_object = new hs_lib_Server();
var login_obj =
server_object.readSystemUserAndPwd(“test.txt”);
if (login_obj)
writeln(“The User is:
”+login_obj.user);
writeln(“The Password is”+login_obj.paswd);
else
writeln(“Identifikation fehlgeschlagen”);
identify
Syntax:
identify(server_name, user, pwd)
Parameter:
server_name: Name des Servers, auf dem die Identifizierung erfolgen
soll. user: Benutzername des zu identifizierenden Benutzers. passwd:
Paßwort des Benutzers.
Returns:
Ein HW_API_Server-Object,
identifiziert wurde.
auf
dem
der
angegebene
Benutzer
Beschreibung: Ein neues HW_API_Server-Objekt wird erzeugt und der Benutzer
identifiziert. Schlägt die Identifikation fehl, so liefert die Methode den
Wert false zurück und eine entsprechende Fehlermeldung wird am
Error-Objekt abgelegt.
Beispiele:
var server_object = new hs_lib_Server();
var the_server =
server_object.identify(www.hwtest.at, ”test”,”test”)
getSystemGroups
Syntax:
getSystemGroups()
Parameter:
keine
Returns:
Array von UGroup-Attributen, die Systemgruppen bezeichnen.
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Beschreibung: Diese Methode liefert alle Gruppennamen zurück, die zu Systemgruppen
gehören. Dazu zählen alle Gruppen, die direkt, oder indirekt von der
Systemgruppe abgeleitet wurden.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var system_groups = server_object.getSystemGroups();
getNosystemGroups
Syntax:
getNoystemGroups()
Parameter:
keine
Returns:
Array von allen UGroup-Attributen, die Nicht-Systemgruppen bezeichnen.
Beschreibung: Diese Methode liefert die Namen alle Gruppen zurück, die keine
Systemgruppen sind. Dazu zählen alle Gruppen, die weder direkt, noch
indirekt von der Systemgruppe abgeleitet wurden.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var system_groups = server_object.getSystemGroups();
isSystemUser
Syntax:
isSystemUser(user_object)
Parameter:
user_object: Eine Instanz des hw_UserObject
Returns:
true, falls das übergebene Benutzerobjekt Systemrechte besitzt.
Beschreibung: Diese Methode liefert als Ergebnis true zurück, falls das übergebene
Benutzerobjekt direkt oder indirekt der Systemgruppe angehört.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var user_object = new hw_UserObject(“test”);
if (server_object.isSystemUser(user_object))
writeln(“Der Benutzer hat Systemrechte!”);
isSystemGroup
Syntax:
isSystemGroup(group_object)
Parameter:
Eine Instanz des hw_GroupObject
Returns:
true, falls das übergebene Gruppenobjekt Systemrechte besitzt.
Beschreibung: Diese Methode liefert als Ergebnis true zurück, falls das übergebene
Gruppenobjekt direkt oder indirekt der Systemgruppe angehört.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var group_object = new hw_GroupObject(“test”);
if (server_object.isSystemGroup(group_object))
writeln(“Die Gruppe hat Systemrechte!”);
108
Kapitel 6: Technischer Entwurf der ausgewählten Variante
getGroupsByIS
Syntax:
getGroupsByIS(Info_Space, system)
Parameter:
Info_Space: Info_Space-Attribut, nach dem gesucht werden soll.
system: ist system
true, so werden auch Systemgruppen
zurückgeliefert. ist system false, so werden nur Nicht-Systemgruppen
zurückgeliefert.
Returns:
aller Gruppen die ein entsprechendes Info_Space-Attribut besitzen.
Beschreibung: Diese Methode liefert alle Gruppen zurück, die ein entsprechendes
Info_Space-Attribut gesetzt haben. Dabei kann zur Angabe von
Informationsräumen auch „*” als Platzhalter für beliebige Zeichen am
Ende angegeben werden. Ist system true, so werden auch
Systemgruppen zurückgeliefert.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var groups =
server_object.getGroupsByIS(“//test/*”,true);
getAllUsersWithIS
Syntax:
getAllUsersWithIS()
Parameter:
keine.
Returns:
Ein Array aller Benutzer, die ein nichtleeres Info_Space-Attribut gesetzt
haben.
Beschreibung: Diese Methode liefert alle Benutzer zurück, die ein nichtleeres
Info_Space-Attribut besitzen.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var users = new server_object.getAllUsersWithIS();
removeSystemGroups
Syntax:
removeSystemGroups(groups)
Parameter:
groups: Array von Gruppenobjekten
Returns:
Array von Gruppenobjekten, die der Funktion übergeben wurden und
keine Systemgruppen sind.
Beschreibung: Diese Methode entfernt aus einem Array von Gruppenobjekten all jene
Gruppen, die direkt oder indirekt von der Systemgruppe abgeleitet wurden.
Beispiele:
var server_object = new hs_lib_Server(“test.pw”);
var all_groups =
server_object.getGroupsByIS(“//test/*”,true);
var nosys_groups =
server_object.removeSystemGroups(all_groups);
109
Kapitel 6: Technischer Entwurf der ausgewählten Variante
110
hw_UserObjectDecorator
erzeugt mit:
hw_UserObjectDecorator-constructor:
new hw_UserObjectDecorator(parameter)
Parameter:
Wird
kein
Parameter
angegeben,
so
hw_UserObjectDecorator-Objekt erzeugt.
wird
ein
leeres
Als Parameter kann optional ein Benutzername angegeben werden, für den
das entsprechende Objekt instanziert werden soll. Die entsprechenden
Methoden beziehen sich dann auf diesen Benutzer.
Beschreibung: Aufgabe des hw_UserObjectDecorator-Objekts ist das Darstellen der
Dialoge zum Anlegen, Editieren und Löschen von Benutzerobjekten.
Properties:
keine
Methoden:
Methode
Beschreibung
showNewUserDlg
Dialog zum Anlegen eines Benutzers
showChangeAttrDlg
Dialog zum Editieren eines Benutzers
showListUsersDlg
Auflistung aller Benutzer
Tabelle 6.19: Methoden des hw_UserObjectDecorator-Objekts
showNewUserDlg
Syntax:
showNewUserDlg(info_space, group_names, user_admin)
Parameters:
info_Space: Informationsräume, denen der angemeldete Benutzer neue
Benutzer hinzufügen kann. group_names: Gruppen zu denen der neue
Benutzer hinzugefügt werden kann. user_admin: der angemeldete
Benutzer.
Beschreibung: Diese Methode zeigt den Dialog zum Einfügen eines neuen Benutzers im
Rahmen der hierarchischen Benutzerverwaltung an. Der momentan am
System angemeldete Benutzer muß dem neuen Benutzer ein
Informationsraum-Attribut, das der Erweiterung seines eigenen entspricht
(siehe Kapitel 5.1.2) zuordnen. Diese Informationsraum-Attribute werden
in dem Parameter info_space der Methode übergeben. Der zweite
Parameter, group_names, enthält ein Array aller Gruppen, denen der neue
Benutzer zugeordnet werden kann. Der neue Benutzer kann nur Gruppen
zugeordnet werden, auf die der angemeldete Benutzer aufgrund seines
eigenen Informationsraum-Attributes Zugriff hat. Der dritte Parameter,
user_admin, übergibt das UName-Attribut des angemeldeten Benutzers an
diese Methode.
Beispiele:
keine
Kapitel 6: Technischer Entwurf der ausgewählten Variante
111
showListUsersDlg
Syntax:
showListUsersDlg(struct, info_ipace, user_is_system)
Parameters:
struct:
Information
für
die
Suchfunktion.
Info_Space:
Informationsräume, denen der angemeldete Benutzer angehört.
user_is_system: Dieses Flag gibt an, ob der angemeldete Benutzer
Systemrechte besitzt.
Beschreibung: Diese Methode zeigt eine Liste aller Benutzer an, auf die der angemeldete
Benutzer auf Grund seines Informationsraum-Attributes Zugriff hat. Diese
Benutzer können vom momentane Benutzer editiert und gelöscht werden.
Beispiele:
keine
showChangeAttrDlg
Syntax:
showChangeAttrDlg(Info_Space, group_names, user_is_system
Parameters:
Info_Space: Informationsräume, denen der angemeldete Benutzer
angehört. Gruppen, denen der angemeldete Benutzer den editierten
Benutzer auf Grund seines Informationsraum-Attributes zuordnen darf.
user_is_system: Dieses Flag gibt an, ob der angemeldete Benutzer
Systemrechte besitzt.
Beschreibung: Diese Methode zeigt einen Dialog an, anhand dessen der angemeldete
Benutzer einen ausgewählten Benutzer editieren kann. Anhand des
Info_Space Attributes wird entschieden, welche InformationsraumAttribute des zu editierenden Benutzers der angemeldete Benutzer
verändern darf.
Beispiele:
keine
hw_GroupObjectDecorator
erzeugt mit:
hw_GroupObjectDecorator constructor:
new hw_GroupObjectDecorator(parameter)
Parameter:
Wird
kein
Parameter
angegeben,
so
hw_GroupObjectDecorator-Objekt erzeugt.
wird
ein
leeres
Als Parameter kann optional ein Gruppenname angegeben werden, für den
das entsprechende Objekt instanziert werden soll. Die entsprechenden
Methoden beziehen sich dann auf dieses Gruppenobjekt.
Beschreibung: Aufgabe des hw_GroupObjectDecorator-Objekts ist die Darstellung der
Dialoge zum Anlegen, Editieren und Löschen von Gruppenobjekten.
Properties:
keine
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Methoden:
Methode
Beschreibung
showNewGroupDlg
Dialog zum Anlegen einer Gruppe
showChangeAttrDlg
Dialog zum Editieren einer Gruppe
showListGroupDlg
Auflistung aller Gruppen
Tabelle 6.20: Methoden des hw_GroupObjectDecorator-Objekts
showNewGroupDlg
Syntax:
showNewGroupDlg(info_space, group_names, user_admin)
Parameters:
info_space: Informationsräume, denen der angemeldete Benutzer neue
Gruppen hinzufügen kann. group_names: Gruppen zu denen die neue
Gruppe hinzugefügt werden kann. user_admin: der angemeldete
Benutzer.
Beschreibung: Diese Methode zeigt den Dialog zum Einfügen einer neuen Gruppe im
Rahmen der hierarchischen Benutzerverwaltung an. Der momentan am
System angemeldete Benutzer muß der neuen Gruppe ein
Informationsraum-Attribut, das der Erweiterung seines eigenen entspricht
(siehe Kapitel 5.1.2) zuordnen. Diese Informationsraum-Attribute werden
in dem Parameter info_space der Methode übergeben. Der zweite
Parameter, group_names, enthält ein Array aller Gruppen, denen die neue
Gruppe zugeordnet werden kann. Die neue Gruppe kann nur Gruppen
zugeordnet werden, auf die der angemeldete Benutzer aufgrund seines
eigenen Informationsraum-Attributes Zugriff hat. Der dritte Parameter,
user_admin, übergibt das UName-Attribut des angemeldeten Benutzers an
die Methode.
Beispiele:
keine
showListGroupsDlg
Syntax:
showListGroupsDlg(struct, info_space, user_is_system)
Parameters:
struct:
Information
für
die
Suchfunktion.
info_space:
Informationsräume, denen der angemeldete Benutzer angehört.
user_is_system: Dieses Flag gibt an, ob der angemeldete Benutzer
Systemrechte besitzt.
Beschreibung: Diese Methode zeigt eine Liste aller Gruppen an, auf die der angemeldete
Benutzer auf Grund seines Informationsraum-Attributes Zugriff hat. Diese
Gruppen können vom momentane Benutzer editiert und gelöscht werden.
Beispiele:
keine
112
Kapitel 6: Technischer Entwurf der ausgewählten Variante
showChangeAttrDlg
Syntax:
showChangeAttrDlg(info_space, group_names, user_is_system
Parameters:
info_space: Informationsräume, denen der angemeldete Benutzer
angehört. group_names: Gruppen, denen der angemeldete Benutzer die
editierte Gruppe auf Grund seines Informationsraum-Attributes zuordnen
darf. user_is_system: Dieses Flag gibt an, ob der angemeldete Benutzer
Systemrechte besitzt.
Beschreibung: Diese Methode zeigt einen Dialog an, anhand dessen der angemeldete
Benutzer eine ausgewählte Gruppe editieren kann. Anhand seines eigenen
Info_Space Attributes wird entschieden, welche InformationsraumAttribute der zu editierenden Gruppe der angemeldete Benutzer editieren
darf.
Beispiele:
keine
Mit diesem Schritt wurde der Entwurf der Objekte für ein System zur hierarchischen
Benutzerverwaltung beendet. Im nächsten Abschnitt sollen nun unter Zuhilfenahme dieser
Objekte jene SSJS-Scripts entworfen werden, welche die Dialoge und Funktionen zur
Durchführung einer hierarchischen Benutzerverwaltung unter Hyperwave bereitstellen.
6.10 Entwurf der SSJS-Scripts
Mit Hilfe der in Kapitel 6.9 entworfenen Objekte können nun die SSJS-Scripts umgesetzt
werden, welche, von Server-Actions angestoßen, dem Benutzer die Dialoge und
Funktionen zur hierarchischen Benutzerverwaltung anbieten. Für jede mögliche Serveraction wird ein eigenes Makro definiert, das die entsprechende Funktionalität
implementiert. Wie bereits in Kapitel 6.5 erwähnt wurde, wird jedes dieser Makros in einer
eigenen Datei abgelegt. Bevor das entsprechende Makro seine eigentliche Aufgabe
ausführt, muß es eine Reihe von Variablen und Objekten instanzieren, die globale Werte
und Parameter festlegen. So muß z.B. jedes Script den Inhalt des vom Benutzer am Client
ausgefüllten Formulars auslesen, bevor irgendwelche Aktionen ausgeführt werden können.
Diese globalen Parameter sollen an zentraler Stelle in einer eigenen Datei initialisiert
werden, die von den Scripts zur hierarchischen Benutzerverwaltung eingebunden werden.
Diese Datei trägt den Namen main.hwt und hat folgende Aufgaben:

Lesen des Hyperwave-Benutzerobjekts des am Client angemeldeten Benutzers.

Lesen der vom Benutzer eingestellten Sprache.

Instanzieren eines hs_lib_Server-Objekts, das den Zugriff auf die InformationraumAttribute von Benutzer- und Gruppenobjekten ermöglicht.

Lesen des Informationsraum-Atribut des am Client angemeldeten Benutzers.
Diese von main.hwt angebotenen Informationen werden von den SSJS-Scripts
ausgewertet, um auf spezielle Eigenschaften des angemeldeten Benutzers reagieren zu
113
Kapitel 6: Technischer Entwurf der ausgewählten Variante
können. Danach kann nun die eigentliche Aufgabe des Scripts ausgeführt werden. Dazu
instanziert das Script in Kapitel 6.9 entworfenen Objekte, um seine Aufgabe durchführen
zu können.
6.11 Dateistruktur der Daten zur
hierarchischen Benutzerverwaltung
Die Dateien, die benötigt werden, um die hierarchische Benutzerverwaltung in den
Hyperwave Information Server einzugliedern, sollen in einem eigenen Verzeichnis
unterhalb des Wavemaster-Verzeichnisses abgelegt werden. Abbildung 6.14 zeigt die
Struktur dieses Verzeichnisses.
wavemaster
master.html
usermanagement
include.hwt
main.hwt
ni_newuser.hwt
...
ni_remove_u_g.hwt
hwlib
hs_lib_Server.js
hw_Object.js
hw_UserManagementObject.js
...
Logfile.js
Error.js
Abbildung 6.14: Die Dateistruktur der hierarchischen Benutzerverwaltung
Alle Daten, die für die hierarchische Benutzerverwaltung benötigt werden, liegen im
Verzeichnis usermanagement. Die Datei „include.hwt“ bindet alle weiteren Dateien für
das System zur hierarchischen Benutzerverwaltung ein. Die Datei main.hwt wird von
allen Scripts zur Initialisierung allgemeiner Parameter aufgerufen (siehe Kapitel 6.10).
Außerdem enthält dieses Verzeichnis alle Makros zur hierarchischen Benutzerverwaltung,
die in Tabelle 6.4 definiert wurden. Die Objekte, die in Kapitel 6.9 zur Umsetzung der
hierarchischen Benutzerverwaltung entworfen wurden, befinden sich in dem Verzeichnis
hwlib. Außerdem enthält dieses Verzeichnis einige Objekt aus der Objektbibliothek
hwlib, die im Rahmen der hierarchischen Benutzerverwaltung benötigt werden.
114
Kapitel 6: Technischer Entwurf der ausgewählten Variante
6.12 Beispiel eines Script-Entwurfes
Da nun alle Komponenten, die zur Umsetzung einer hierarchischen Benutzerverwaltung
unter Hyperwave benötigt werden, entworfen wurden, soll im folgenden Kapitel anhand
eines konkreten Beispiels der Entwurf eines Scripts erfolgen Als Beispiel soll
angenommen werden, daß der Benutzer den Menüpunkt Admin/Benutzer/neuer
Benutzer wählt, um einen neuen Benutzer im Rahmen der hierarchischen
Benutzerverwaltung anzulegen. Der Entwurf aller weiteren Scripts erfolgt nach demselben
Prinzip. An dieser Stelle soll noch darauf hingewiesen werden, daß diese Scripts der im
Anhang 2 beiliegenden CD entnommen werden können.
Wie bereits in Kapitel 6.3 erwähnt wurde, erfolgt der Aufruf der Scripts zur hierarchischen
Benutzerverwaltung über Server-Actions. Die Server-action wird, in der URL codiert, zum
Server übertragen. Dort wird in den Wavemaster-Templates mittels der
Programmiersprache PLACE anhand der übermittelten Server-action ein entsprechendes
Makro gestartet. Dieses Makro führt den notwendigen Code aus, um die vom Benutzer
gewünschte Aktion auszuführen. (siehe auch Kapitel 4.7)
Wählt der Benutzer den Menüpunkt Admin/Benutzer/neuer Benutzer, um einen
neuen Benutzer anzulegen, so übermittelt der Browser die Server-action
dialogs.ni_newuser.action zum Server. Anhand dieser Server-action wird im
Wavemaster-Template master.html in das Makro NI_dialog_newuser verzweigt. Im
ersten Schritt, noch bevor das eigentliche SSJS-Script, das den Dialog zum Anlegen eines
Benutzers erzeugt, gestartet wird, erfolgt die Einbindung der Datei main.hwt in das
entsprechende Makro. Aufgabe dieser Datei ist, allgemeine Parameter und Variablen zu
initialisieren, die von allen Scripts zur hierarchischen Benutzerverwaltung benötigt
werden. Danach wird das eigentliche SSJS-Script ausgeführt. Beispiel 6.2 zeigt den Code
des Makros NI_dialog_newuser. Der eigentliche SSJS-Code, der den Dialog zum
Anlegen eines neuen Benutzers erzeugt, wird über den <SERVER> und den </SERVER>Tag eingebunden. Dieses SSJS-Script läuft in folgenden Schritten ab:

Das Script wird nur gestartet, wenn bis zu dieser Stelle (d.h. in main.hwt) kein Fehler
aufgetreten ist.

Es wird eine Meldung in das in main.hwt instanzierte Logfile geschrieben.

Es werden die Gruppen bestimmt, zu denen der aktuelle Benutzer neue Benutzer
zuweisen darf.

Ein neues hw_UserObjetctDecorator-Objekt wird erzeugt.

Die Methode showNewUserDlg des hw_UserObjectDecorator-Objekts wird
aufgerufen, um den Dialog zum Erzeugen eines neuen Benutzers zu erzeugen.

Es wird eine Meldung in das Logfile geschrieben.

Das Logfile wird geschlossen.
Mit dem Schließen des Logfiles im letzten Schritt des Scripts ist die Abarbeitung des
Requests an den Server beendet.
115
Kapitel 6: Technischer Entwurf der ausgewählten Variante
%%macro NI_dialog_newuser%%
%%include "NetinfoCommon/Benutzerverwaltung/main.hwt"%%
<SERVER>
if (!errorObj.size())
{
logFile.writeln("show new user-dialog");
var group_names = server_object.getGroupsByIS(remote_user_IS,
remote_user_is_system);
var dummy = new hw_UserObjectDecorator();
dummy.showNewUserDlg(remote_user_IS, group_names,
remote_user["UName"]);
logFile.writeln("show new user-dialog done.");
}
logFile.close();
</SERVER>
%%endmacro%%
Beispiel 6.2: Dieses Script erzeugt einen Dialog zum Anlegen eines neuen Benutzers.
Am Ende dieses Kapitels soll nun die Implementierungsphase der vorliegenden Arbeit im
Detail geplant werden.
6.13 Planung der Implementierungsphase
Nachdem nun alle für die hierarchische Benutzerverwaltung benötigten Objekte, Dialoge
und Scripts entworfen wurden, soll am Ende dieses Kapitels die Durchführung der
Implementationsphase der vorliegenden Arbeit im Detail geplant werden. Außerdem muß
an dieser Stelle überprüft werden, ob der in Kapitel 2.5.1 nur grob geschätzte Aufwand für
die Durchführung der Implementierungsphase mit den in diesem Kapitel neu gewonnenen
Ergebnissen noch übereinstimmt. Tabelle 6.21 listet die Teilprozesse der
Implementierungsphase auf, die nun, nach der in diesem Kapitel durchgeführten
Entwurfsphase des Projekts „Hierarchische Benutzerverwaltung unter Hyperwave“, genau
bekannt sind.
116
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Implemetation von...
Aufwand [in Tagen]
hw_UserManagementObject
3
hw_UserObject
1
hw_GroupObject
1
hs_lib_Server
5
hw_UserObjectDecorator
8
hw_GroupObjectDecorator
8
Scripts
20
Summe
46
Tabelle 6.21: Aufwandsabschätzung der Teilprozesse in der Implementierungsphase.
Wie Tabelle 6.21 entnommen werden kann, beträgt der an dieser Stelle geschätzte
Aufwand für die Implementierung des Systems zur hierarchischen Benutzerverwaltung 44
Tage. In Kapitel 2.5.1 wurden in einer ersten Annäherung für die Implementierung der
hierarchischen Benutzerverwaltung 50 Tage veranschlagt. Die Differenz von 6 Tagen kann
in diesem Rahmen als der übliche „Polster“ von ca. 10% des geschätzten Aufwandes zur
Absicherung von unvorhergesehenen Schwierigkeiten in der Implementationsphase
eingerechnet werden. Somit müssen an dieser Stelle keine Korrekturen des in Kapitel 2.5.3
erstellten Projektplans vorgenommen werden.
6.14 Schlußbemerkung
Aufgabe dieses Kapitels war die detaillierte Planung eines Systems zur hierarchischen
Benutzerverwaltung durchzuführen. Noch bevor mit der Entwicklung der Funktionalität
des Systems begonnen werden konnte, mußte entschieden werden, auf welche Weise das
System in den Hyperwave Information Server eingebunden werden sollte. Es standen die
drei Möglichkeiten PLACE, CGI-Scripts oder SSJS zur Verfügung, um die hierarchische
Benutzerverwaltung in Hyperwave zu integrieren. Es wurde entschieden, die
Benutzerverwaltung über SSJS in Hyperwave einzubinden, da diese Methode einfach
umzusetzen und zugleich auch die leistungsfähigste Methode ist.
Nachdem eine konkrete Möglichkeit ausgewählt wurde, konnte mit der Entwicklung der
Dialoge zur hierarchischen Benutzerverwaltung und deren Zusammenspiel untereinander
begonnen werden. Die neuen Dialoge und deren Verhalten orientiert sich an den StandardDialogen des Hyperwave Information Servers zur Benutzerverwaltung. Anhand von EventDiagrammen wurde das Zusammenspiel der einzelnen Dialoge und Funktionen analysiert,
bevor die daraus gewonnenen Ergebnisse zum Entwurf der Dialoge zur hierarchischen
Benutzerverwaltung angewendet wurden. Nachdem die Dialoge der hierarchischen
Benutzerverwaltung entworfen wurden, konnte mit dem objektorientierten Entwurf der
117
Kapitel 6: Technischer Entwurf der ausgewählten Variante
Funktionalität der hierarchischen Benutzerverwaltung begonnen werden. Der
objektorientierte Entwurf wurde aus zwei Gründen gewählt: Erstens bietet das OOD eine
Menge Vorteile: Der Code ist leicht wartbar, sehr modular und auch zu einem hohen Grade
wieder verwendbar. Der zweite Grund, warum OOD als Entwurfsprinz für die
hierarchische Benutzerverwaltung gewählt wurde ist, daß für die hierarchischen
Benutzerverwaltung programmierte Funktionalität auch in die am IICM in JavaScript
programmierte Objektbibliothek hwlib eingebunden werden sollte.
Nachdem die auch die Objekte für die hierarchische Benutzerverwaltung entworfen
wurden, konnten schließlich die SSJS-Scripts umgesetzt werden, die unter Zuhilfenahme
der entworfenen Objekte die tatsächlichen Funktionen der hierarchischen
Benutzerverwaltung, wie „neuen Benutzer erzeugen“ oder „Gruppe editieren“ anbieten.
Am Ende dieses Kapitels wurde schließlich noch die in Kapitel 2.5.1 vorgenommene, sehr
grob geschätzte Aufwandsabschätzung für die im nächsten Kapitel folgende
Implementierungsphase überprüft.
Im nächsten Schritt des Projekts „hierarchische Benutzerverwaltung unter Hyperwave“
muß die in diesem Kapitel entworfenen Funktionalität nun tatsächlich in ausführbaren
Code übersetzt werden. Das nächste Kapitel beschäftigt sich daher mit der
Implementierung der hierarchischen Benutzerverwaltung, den dazu eingesetzten Tools und
Programmierrichtlinien für das Projekt „hierarchische Benutzerverwaltung unter
Hyperwave“.
118
Kapitel 7
Die Implementierungsphase
7.1 Einleitung
Dieses Kapitel beschäftigt sich mit der Implementierung des in dieser Arbeit
ausgearbeiteten Projekts „hierarchische Benutzerverwaltung unter Hyperwave“. In der
Implementierungsphase muß Programmcode implementiert werden, der das in Kapitel 6
entworfene Design für eine hierarchische Benutzerverwaltung unter Hyperwave umsetzt.
In diesem Kapitel soll daher zunächst auf die Umgebung eingegangen werden, in der das
System zur hierarchischen Benutzerverwaltung implementiert werden soll. Dazu zählen
der Hyperwave Server, in den die hierarchische Benutzerverwaltung eingebunden werden
soll, das verwendete Betriebssystem und die zur Implementierung verwendeten Tools wie
Editoren, usw. Im zweiten Abschnitt dieses Kapitels sollen die Programmierrichtlinien für
die Implementierung einer hierarchischen Benutzerverwaltung festgelegt werden. Die
Entwicklung des Codes für ein System zur hierarchischen Benutzerverwaltung muß auf
eine Weise erfolgen, so daß der Code auch für andere Entwickler leicht verständlich ist.
Die einfache „Lesbarkeit“ des Codes ist während der Testphase und vor allem für spätere
Erweiterungen des Codes von großer Wichtigkeit. Den Abschluß des Kapitel 7 bildet die
Beschreibung der tatsächlichen Implementierung.
Bevor nun auf die Programmierrichtlinien für dieses Projekt eingegangen wird, soll im
ersten Abschnitt dieses Kapitels, wie bereits angesprochen, auf die Umgebung und die
Tools eingegangen werden, mit denen das System zur hierarchischen Benutzerverwaltung
entwickelt werden soll.
7.2 Umgebung und Tools
In diesem Abschnitt werden die Umgebung und die Tools beschrieben, mit deren Hilfe das
System zur hierarchischen Benutzerverwaltung implementiert werden soll. Dazu zählen
das Betriebssystem, unter dem die hierarchische Benutzerverwaltung umgesetzt werden
soll, der Hyperwave Information Server, in den die hierarchische Benutzerverwaltung
Kapitel 7: Die Implementierungsphase
120
integriert werden soll, sowie alle weiteren Tools, wie Editoren HTML-Parser, usw., die zur
Implementierung der hierarchischen Benutzerverwaltung verwendet werden.
a) Betriebssystem
Die Implementierung des Systems zur hierarchischen Benutzerverwaltung erfolgt auf dem
am IICM eingerichteten UNIX-System. Diese Variante wurde aus folgenden Gründen
gewählt:

Die Implementierung der hierarchischen Benutzerverwaltung liegt dadurch in einem
Bereich des Systems, der durch tägliche Backups gegen Datenverlust gesichert ist.

Der Auftraggeber betreibt den Hyperwave Information Server ebenfalls in einer UNIXUmgebung.
b) Hyperwave Server
Das System zur hierarchischen Benutzerverwaltung soll in einen internen, zu
Entwicklungszwecken am IICM installierten Hyperwave Information Server der Version
4.1 eingebunden werden. Dieser Ansatz wurde gewählt, da der Auftraggeber ebenfalls
einen Hyperwave Server der Version 4.1 einsetzt. Um eine maximale Kompatibilität mit
dem System des Auftraggebers zu erreichen, soll daher auch intern die Entwicklung eines
Systems zur hierarchischen Benutzerverwaltung auf einem Server der Version 4.1
vorgenommen werden.
Durch die Trennung von Präsentation und Inhalt der Daten, wie sie von dem Hyperwave
Information Server vorgenommen wird, kann dabei folgendermaßen vorgegangen werden:
Im Home-Verzeichnis des Entwicklers wird ein eigenes Wavemaster-Verzeichnis angelegt,
in das die Standard-Templates des Hyperwave Information Servers 4.1 kopiert werden.
Der Entwickler nimmt die Implementierung des Systems zur hierarchischen
Benutzerverwaltung vor, indem er diese Templates entsprechend des in Kapitel 6
entwickelten Systems zur Umsetzung einer hierarchischen Benutzerverwaltung abändert.
Um diese Templates auszuführen, startet der Entwickler einen eigenen Wavemaster-Prozeß
in seinem Home-Verzeichnis. Wie in Abbildung 7.1 dargestellt, kommuniziert dieser
Wavemaster-Prozeß über das interne HG-CSP Protokoll mit dem Session-Layer des
tatsächlichen Hyperwave Servers, und stellt dessen Daten entsprechend der abgeänderten
Templates dar (siehe auch Kapitel 4.5 und Kapitel 4.6). Durch diese Arbeitsweise kann
verhindert werden, daß die Implementierung der hierarchischen Benutzerverwaltung die
Arbeit
anderer
Entwickler
auf
dem
selben
Server
beeinflußt.
Kapitel 7: Die Implementierungsphase
121
Browser
HTTP
HG-CSP
80
418
wavem
aster
gophga
te
snmpa
gent
Wavemaster
hgserv
er
ftserver
Entwicklungs-Rechner
dbserv
er
dcserv
er
Hyperwave-Server
Abbildung 7.1: Arbeitsweise mit dem Hyperwave Information Server zur Implementierung
eines Systems zur hierarchischen Benutzerverwaltung.
c) Tools
In diesem Abschnitt soll festgelegt werden, welche Tools für die Implementierung der
hierarchischen Benutzerverwaltung eingesetzt werden sollen:

Editor: Als Editor zur Erstellung des benötigten Programmcodes soll der unter Unix
weit verbreitete Editor GNU Emacs45 zum Einsatz kommen. Dieser Editor bietet eine
Vielzahl von Konfigurationsmöglichkeiten, wie Text-Highlighting und ausführen
vordefinierter Code-Makros.

HTML-Parser: Um die Korrektheit des HTML-Codes zu überprüfen, der den
Dialogen der hierarchischen Benutzerverwaltung zugrunde liegt soll der als Freeware
verbreitete HTML-Parser HTML-Validat V1.046 eingesetzt werden.

Browser: Um die Darstellung der Dialoge zur hierarchischen Benutzerverwaltung zu
überprüfen, sollen die Browser Netscape 4.0 und Microsoft Explorer 4.0 eingesetzt
werden. Da diese beiden Browser einige HTML-Tags unterschiedlich interpretieren,
muß die optische Darstellung der Dialoge immer mit beiden Browser überprüft werden.
In diesem Abschnitt wurde auf die Umgebung und die Tools eingegangen, die eingesetzt
werden sollen, um das System zur hierarchischen Benutzerverwaltung zu implementieren.
Im nächsten Abschnitt sollen nun auf die Richtlinien eingegangen werden, die bei der
Implementierung des Programmcodes beachtet werden müssen.
45
46
http://www.gnu.org/manual/emacs-20.3/emacs.html
http://www.hoh-net.de/software/validat.htm
Kapitel 7: Die Implementierungsphase
122
7.3 Richtlinien
In diesem Abschnitt sollen Richtlinien festgelegt werden, nach denen die Implementierung
des Programmcodes für das System zur hierarchischen Benutzerverwaltung unter
Hyperwave erfolgen soll. In der Praxis erfolgt die Entwicklung von Programmcode in
Teams. Viele Personen sind an der Entwicklung des Codes beteiligt und müssen diesen
auch verstehen können. Aus diesem Grund ist es notwendig Programmierrichtlinien47
festzulegen, die von allen Entwicklern im Rahmen des Projekts beachtet werden müssen.
Der zweite Grund, warum Programmierrichtlinien festgelegt werden ist, um bereits von
vornherein bestimmte Verhaltensweisen des System zu vereinheitlichen. So kann z.B.
durch Programmierrichtlinien festgelegt werden, daß nach Auftreten eines internen Fehlers
immer eine bestimmte Fehlerbehandlungsroutine ausgeführt werden muß. Solche
Programmierrichtlinien erleichtern die Fehlersuche und tragen zur Erhöhung der Stabilität
des Systems bei.
Generelle Regeln
Der Programmcode muß so verfaßt werden, daß dieser intuitiv verstanden werden kann,
ohne zu viele Kommentare lesen oder den Autor des Codes fragen zu müssen. Diese Regel
gilt vor allem für Namen von Variablen und Methoden. Methoden müssen so kurz wie
möglich sein. Die Länge von Methoden sollte 60 Zeilen nicht überschreiten, es sei denn,
diese Überschreitung ist unvermeidbar. Codezeilen dürfen auf keinen Fall die Länge von
108 Zeichen überschreiten. Jedes Objekt muß in einer eigenen Datei abgelegt werden. Falls
unsauber programmierte Codestücke (Hacks) unvermeidbar sind, (z.B. muß ein Termin
unbedingt eingehalten werden ) müssen diese unbedingt durch Kommentare der in Beispiel
7.1 dargestellten Form eingeschlossen werden.
// FIXXME (<author, date>) -> <description of the hack>
[..... hack .....]
// END FIXXME (<author, date>)
Beispiel 7.1: Beispiel eines „Hacks“
Das Schlüsselwort FIXXXME muß in Großbuchstaben geschrieben werden und mindestens
zwei „X” beinhalten. Mehr als zwei „X” sind erlaubt und sollten zur Kennzeichnung von
„schlimmen Hacks“ eingesetzt werden. Um so mehr „X” das Wort FIXXXME beinhaltet, um
so gravierender ist der Hack. Maximal sind fünf „X” erlaubt. Diese Richtlinie hilft dabei
Hacks schnell zu finden. Alle Hacks, die ihren Weg in den Programmcode gefunden haben
müssen so schnell wie möglich wieder entfernt werden.
47
Diese Richtlinien haben sich aus der Erfahrung und Projektentwicklung am IICM im
Laufe der Jahre entwickelt.
Kapitel 7: Die Implementierungsphase
123
Behandlung konzeptueller Probleme
Sobald die Erweiterung oder Änderung eines Codestückes zu kompliziert wird,
(Seiteneffekte, keine korrekte Lösung möglich, usw.) wird das entsprechende Codestück
als Hack betrachtet und durch einen FIXXXME-Kommentar als ein solcher gekennzeichnet.
Obwohl diese Forderung zu einem kompletten Redesign des gesamten Codes führen
könnte, können Seiteneffekte und Hacks nicht toleriert werden!
Sprache
Kommentare müssen in englisch verfaßt werden, genauso alle Namen von Objekten,
Variablen und Methoden. Es sind keine Ausnahmen erlaubt!
Dateiköpfe
Jede Datei muß an deren Beginn ein Copyright-Statement der in Beispiel 7.2 dargestellten
Form beinhalten.
/***********************************************************************
* Copyright (c) 1999 IICM, Graz University of Technology, Austria.
*
* This software is the confidential and proprietary information of IICM,
* Graz University of Technology, Austria. You shall not disclose such
* Confidential Information and shall use it only in accordance with the
* terms of the license agreement you entered into with IICM.
*
* IICM MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE
* SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
* IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
* PURPOSE, OR NON-INFRINGEMENT. IICM SHALL NOT BE LIABLE FOR ANY DAMAGES
* SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING
* THIS SOFTWARE OR ITS DERIVATIVES.
***********************************************************************/
Beispiel 7.2: Dateikopf
Namenskonventionen
Neben den allgemeinen Programmierrichtlinien, die in diesem Abschnitt beschrieben
werden, sollen an dieser Stelle auch spezielle Namenskonventionen für
Variablenbezeichnungen festgelegt werden:
Objekte:
AllWordsCapitalizedWithoutUnderscores
Methoden:
firstWordLowerCaseAllOthersCapitalizedWithoutUnderscores
Kapitel 7: Die Implementierungsphase
124
Konstanten:
ALL_UPPER_CASE_WITH_UNDERSCORES
Membervariablen:
all_lower_case_with_underscores_and_with_trailing_underscore_
Lokale variablen:
all_lower_case_with_underscores
Spezielle Methodenbezeichnungen
Alle Methoden, die Variablen von Objekten verändern, müssen setXXX benannt werden.
Die Methoden, die Werte bestimmter Variablen von Objekten zurück liefern werden in
zwei Kategorien unterteilt: Jene, die Bool’sche Werte48 zurück liefern werden isXXX
genannt, alle anderen getXXX. Beispiel 7.3 zeigt die Definition einer setXXX-Methode.
function setCounter(int)
{
[..... code .....]
}
Beispiel 7.3: Beispiel für eine setXXX- Methode.
Zähler, Schleifen
Zähler dürfen nicht mit einzelnen Buchstaben bezeichnet werden. Zählervariablen müssen
genauso wie alle andere Variablen einen eindeutigen und sinnvollen Namen besitzen. Der
Grund für diese Forderung ist, daß Zählervariablen, die aus einzelnen Buchstaben
bestehen, Operationen wie Suchen bzw. Suchen & Ersetzen unmöglich machen, da auch
alle anderen Vorkommnisse des entsprechenden Buchstabens gefunden werden.
Fehlerbehandlung von Methoden des HW_API_Server-Objekts
Eventuelle Fehler (HW_API_Error), die bei Methodenaufrufen des HW_API_Servers
zurückgeliefert werden, müssen abgefangen werden. Daher muß nach JEDEM(!) Aufruf
einer HW_API_Server-Methode eine Fehlerbehandlungsroutine folgen. Dieser Codeteil
muß zumindest folgende Operationen ausführen:

48
Pushen des gesamten HW_API_Error-Objekts auf das vordefinierte hwlib_ErrorObjekt. Durch diese Forderung wird die Entstehungsgeschichte des Fehlers in der
true, false
Kapitel 7: Die Implementierungsphase
125
Instanz des hwlib_Error-Objekts aufgezeichnet. Anhand des hwlib_Error-Objekts
kann später im Code entschieden werden, ob bereits ein Fehler aufgetreten ist und
entsprechend durch Ausgabe einer Fehlermeldung, usw. darauf reagiert werden.
Außerdem kann dadurch die Entstehungsgeschichte des Fehlers für Debug-Zwecke
zurückverfolgt werden.

Schreiben der vom Server zurückgelieferten Fehlermeldungen in das Logfile. Durch
dieses Verhalten ist das Auftreten eines Fehlers immer anhand des Logfiles erkennbar.
Optional sollte auch vom Programmierer eine zusätzliche Meldung erzeugt werden, welche
die Ursache des Fehlers im Zusammenhang mit dem Code genauer beschreibt. Die
Ausgabe von Fehlermeldungen erfolgt immer in englischer Sprache. Beispiel 7.4 zeigt das
Codelisting einer solchen Fehlerbehandlungsroutine.
var out =
server.find({keyquery:"Name=basecoll“,languages:Array("en")});
if (out.error.error())
{
var msg = "error searching for base collection";
errorObj.push(msg);
errorObj.push(out.error);
logFile.writeln(msg);
for (var e_cnt in out.error)
logFile.writeln(out.error[e_cnt].description("en"));
}
Beispiel 7.4: Behandlung von Fehlermeldungen der HW_API_Server-Methoden
7.4 Implementierung
An dieser Stelle soll nun die tatsächliche Implementierung der hierarchischen
Benutzerverwaltung unter Hyperwave nach den in Abschnitt 7.3 festgelegten Richtlinien
erfolgen. Im ersten Schritt sind die in Kapitel 6.9 beschriebenen Objekte zu codieren. Nach
der Methode des objektorientierten Designs (siehe Kapitel 6.8), das zur Entwicklung dieser
Objekte benutzt wurde, sind keine weiteren Iterationen notwendig, welche die Aufgabe
haben, die Funktionalität dieser Objekte weiter zu verfeinern. Daher kann die Umsetzung
der Objekte zur hierarchischen Benutzerverwaltung so, wie in Kapitel 6.9.4 beschrieben,
erfolgen. Im zweiten Schritt sind die in Kapitel 6.10 konzipierten SSJS-Scripts zu
implementieren, welche die Dialoge und Funktionen der hierarchischen
Benutzerverwaltung mit Hilfe der im ersten Schritt codierten Objekte umsetzen. Die
Implementierung des Systems zur hierarchischen Benutzerverwaltung soll nach der in
Kapitel 6.13 festgelegten Reihenfolge erfolgen.
An dieser Stelle soll noch angemerkt werden, daß der fertiggestellte Programmcode des
Systems zur hierarchischen Benutzerverwaltung für den Hyperwave Information Server
4.1 der in Anhang 2 beiliegenden CD entnommen werden kann.
Kapitel 7: Die Implementierungsphase
126
7.5 Schlußbemerkung
Dieses Kapitel beschäftigte sich mit der Implementierungsphase des Systems zur
hierarchischen Benutzerverwaltung unter Hyperwave. Es wurden die Umgebung und die
eingesetzten Tools beschrieben, mit denen der Programmcode für die hierarchische
Benutzerverwaltung entwickelt werden soll. Weiters wurden Programmierrichtlinien
festgelegt, die bei der Implementierung des Programmcodes eingehalten werden müssen.
Programmierrichtlinien werden aus zwei Gründen festgelegt: Erstens muß die Lesbarkeit,
Einheitlichkeit und Verständlichkeit des Programmcodes gesichert werden. Zweitens soll
durch die Programmierrichtlinien die Reaktion des System auf bestimmte Ereignisse
festgelegt werden, um ein einheitliches Verhalten des Codes zu erreichen. Im Anschluß
daran wurde die tatsächliche Implementierung des Systems zur hierarchischen
Benutzerverwaltung unter Hyperwave vorgenommen. Im ersten Schritt erfolgte die
Codierung der in Kapitel 6.9 entworfenen Objekte zur Realisierung einer hierarchischen
Benutzerverwaltung. Im zweiten Schritt wurde, auf diesen Objekten basierend, die
Umsetzung der in Kapitel 6.12 beschriebenen SSJS-Scripts vorgenommen. Sowohl die
Implementierung der Objekte, als auch die Umsetzung des SSJS-Scripts mußten nach den
in Abschnitt 7.3 festgelegten Richtlinien erfolgen.
Diese Implementierungsphase nimmt im Projektverlauf am meisten Zeit in Anspruch, da
die tatsächliche Umsetzung des entworfenen Systems in ausführbaren Programmcode
erfolgt. Nach dem Abschluß der Implementierung folgt nach dem in Kapitel 2.5.3
festgelegten Projektplan die Testphase, in der geprüft werden muß, ob der fertig
umgesetzte Programmcode die geforderte Funktionalität auch fehlerfrei umsetzt.
Kapitel 8
Testphase
8.1 Einleitung
An dieser Stelle muß nun überprüft werden, ob das bereits implementierte System zur
hierarchischen Benutzerverwaltung fehlerfrei arbeitet und seinen Anforderungen
entspricht. Im wesentlichen muß geprüft werden, ob die in Kapitel 3.4 beschriebenen
Systemanforderungen durch das implementierte System erfüllt werden. Dazu soll in drei
Phasen vorgegangen werden:49

Unit Testing: In der ersten Phase wird die korrekte Funktionalität der einzelnen
Module des Systems getestet. Dazu werden Testfälle erzeugt, um zu zeigen, daß die
einzelnen Module die in der Designphase entworfene Funktionalität korrekt umsetzen.

Integration Testing: Aufgabe der zweiten Testphase ist es, die Module, die bereits
durch einen Unit Test überprüft wurden, zu einem funktionsfähigen System
zusammenzusetzen. Dabei wird das System schrittweise erweitert, um beim Auftreten
eines Fehlers leicht feststellen zu können, durch welches Modul der Fehler verursacht
wurde.

System Testing: In der letzten Testphase wird schließlich das fertiggestellte
Gesamtsystem überprüft. Ziel dieser Testphase ist zu prüfen, ob von dem System die
Systemanforderungen korrekt umgesetzt werden.
Bevor auf die Testphase des in dieser Arbeit beschriebenen Systems zur hierarchischen
Benutzerverwaltung unter Hyperwave eingegangen wird, sollen im folgenden Abschnitt
die Aufgaben der einzelnen Testphasen genauer untersucht werden.
49
nach Pfleeger [Pfl98]
Kapitel 8: Testphase
128
8.2 Ablauf der Testphase
Nach dem Modell von Pfleeger [Pfl98] gliedert sich die Testphase in die drei Teilphasen
Unit Testing, Integration Testing und System Testing, die an dieser Stelle genauer
untersucht werden sollen.
8.2.1
Unit Testing
Ziel der Unit Testing Phase ist, fehlerhaften Programmcode aus den entwickelten Modulen
zu entfernen. Unter dem Begriff „Module“ können in diesem Zusammenhang einzelne
Funktionen, Klassen oder ganze Funktionsbibliotheken verstanden werden. [Pfl98]
Im ersten Schritt wird der Programmcode der Module inspiziert. Dabei sollte der
Programmcode mit dem Design der Funktionalität des entsprechenden Moduls verglichen
werden, um sicherzustellen, daß die entworfene Funktionalität korrekt umgesetzt wurde. In
der Literatur sind viele Methoden bekannt, um den Programmcode von Modulen zu
inspizieren. In sogenannten Code Reviews wird ein Team aus dem Verfasser des
Programmcodes und drei oder vier weiteren technischen Experten gebildet. Diese
technischen Experten können andere Programmierer, Designer oder Projektleiter sein.
Außer diesen Personen sind ein Moderator, der das Review leitet, und ein Schriftführer
anwesend, der währen des Reviews Protokoll führt. Während dem Review erklärt der
Programmierer den anwesenden Personen die Funktionsweise des von ihm umgesetzten
Programmcodes. Die anwesenden Experten haben die Aufgabe, die korrekte Umsetzung
des Codes anhand des Design zu prüfen. Treten Diskrepanzen zwischen dem Vortragenden
und dem Expertenteam, auf so werden diese in der Gruppe diskutiert. Aufgabe des
Schriftführers ist, die Ursachen für diese Diskrepanzen festzuhalten. [Pfl98]
Eine weitaus informalere Methode, um Code zu inspizieren sind sogenannte Code WalkTroughs. Bei einem Code Walk-Trohgh setzen sich mehrere Experten und der
Programmierer des Codes zusammen, um den Code auf seine Korrektheit zu überprüfen.
Die Atmosphäre ist sehr informal, die Aufmerksamkeit gilt dem Code und nicht dem
Programmierer. Nachdem der Code inspiziert und etwaige Fehler oder Inkosistenzen
behoben wurden, wird im nächsten Schritt der Code compiliert, um restliche Sytax-Fehler
zu entfernen. Im letzten Schritt werden schließlich Testfälle implementiert, um zu zeigen,
daß die entwickelten Module die gewünschte Funktionalität korrekt umsetzen. [Pfl98]
Bei der Umsetzung von Testfällen muß beachtet werden, daß durch das Testen von
Programmcode keineswegs dessen Korrektheit bewiesen wird. Der Vorgang des Testens
entspricht eher einer Reihe von „Experimenten“, deren Ergebnisse als eine Basis für die
Entscheidung dient, wie sich das Programm in bestimmten Situationen verhalten wird. Um
die Korrektheit des den Programmcodes zu beweisen müssen formale Beweismethoden
angewandt werden. Diese Beweismethoden sind mit erheblichem Aufwand verbunden. Im
Allgemeinen ist der Korrektheits-Beweis einer Funktion aufwendiger als die
Implementierung derselben Funktion. [Pfl98] Da dieser Aufwand im Rahmen des
vorliegenden Projekts nicht vertretbar ist, soll an dieser Stelle nicht näher auf formale
Beweismethoden eingegangen werden, sondern in diesem Zusammenhang auf [FME99]
hingewiesen werden.
Kapitel 8: Testphase
129
Um den Programmcode zu testen müssen Testdaten erzeugt werden. Das zu testende
Modul manipuliert diese Testdaten und erzeugt so ein bestimmtes Ergebnis. Die
Testdatensätze, oder Testpunkte müssen so gewählt werden, daß deren Ergebnisse
bestimmte Aussagen über das Verhalten des Codes treffen. Eine endliche Menge solcher
Testdatensätze wird als Test bezeichnet. [Pfl98]
Welche Testdatensätze gewählt werden sollen, ist eine komplexe Aufgabe. Im allgemeinen
können folgende Regeln zur Wahl von Testdaten verwendet werden: [Pfl998]
Im ersten Schritt wird das zu testende Modul als geschlossenes System betrachtet. Dabei
wird nur die Schnittstelle des Moduls zur Außenwelt zur Erzeugung von Testfällen
betrachtet. Dabei sollen sowohl typische Fälle, als auch Extremfälle sowie ungültige
Eingabedaten als Testfälle herangezogen werden. Erwartet die Schnittstelle einer Funktion
z.B. eine positive Zahl als Eingabewert, so könnten folgende Daten als Testfälle verwendet
werden:

eine sehr große, positive Zahl

eine positive Zahl

Eine Zahl größer 0 aber kleiner 1

null

eine negative Zahl
Im zweiten Schritt wird die interne Struktur des Programms betrachtet. Dadurch können
weitere Testfälle erzeugt werden. Es können Testfälle erzeugt werde, die alle internen
Verzweigungen des Moduls durchlaufen. Falls Programmschleifen im Code des Moduls
enthalten sind, können Testdaten erzeugt werden, die diese Schleifen einmal, öfters oder
auch gar nicht durchlaufen. Verwendet das Modul intern z.B. trigonometrische Funktionen,
so können Testdaten erzeugt werden, welche die Extremwerte 0°, 90°, 180°, usw.
erzeugen. [Pfl98]
8.2.2
Integration Testing
Nach der Phase des Unit Testings, in der die einzelnen Module des Systems unabhängig
voneinander getestet wurden, werden diese schrittweise zu einem funktionsfähigen System
zusammengesetzt. Die Integration der einzelnen Module muß geplant werden, um im
Fehlerfall leicht feststellen zu können, durch welches Modul der Fehler verursacht wurde.
Dabei können zwei unterschiedliche Strategien verwendet werden: Top Down Testing und
Bottom Up Testing. [Pfl98]
Bei der Methode des Top Down Testings werden zuerst alle Komponenten auf der
untersten hierarchischen Ebene des gesamten Systems einem Unit-Test unterzogen. Im
nächsten Schritt werden jene Komponenten getestet, die auf die den zuvor getesteten
Module aufbauen. Diese Vorgehensweise wird weiterverfolgt, bis schließlich alle Module
des System getestet wurden. Diese Testmethode ist vor allem dann sinnvoll, wenn viele der
Module auf der untersten Ebene von mehreren darüberliegenden Modulen verwendet
werden. [Pfl98] Um z.B. die in Abbildung 8.1 gezeigte Hierarchie zu Testen, muß nach
Kapitel 8: Testphase
130
dem Schema aus Abbildung 8.2 vorgegangen werden.
A
B
E
C
F
D
G
Abbildung 8.1: Beispiel für eine Hierarchie von Modulen in einem System
Test
E
Test
B, E, F
Test
F
Test
C
Test
G
Test
A, B, C, D,
E, F, G
Test
D, G
Abbildung 8.2: Bottom Up Testing
Die zweite Strategie, die eingesetzt werden kann, um das Zusammenspiel der einzelnen
Module zu testen, ist Top Down Testing. Top Down Testing ist in gewisser Weise der
umgekehrte Prozeß des Bottom Up Testings. Am Beginn wird ein Element der obersten
Ebene getestet. Diese Elemente sind üblicherweise Kontrollelemente, wie z.B. ein
Menüpunkt oder Button zum Start einer Berechnungsroutine, usw. Im nächsten Schritt
werden alle Module eingebunden, die durch das Modul auf der oberster Ebene aufgerufen
werden und dieses System getestet. Dieser Vorgang wird solange wiederholt, bis
schließlich alle Module eingebunden und getestet wurden. Um die Funktionalität von
Modulen zu simulieren, die noch nicht getestet wurden, werden sogenannte Stubs
entwickelt. Ein Stub ist ein Codestück, daß die Funktion eines Moduls simuliert, indem
z.B. ein fix codierter und nicht berechneter Wert zurückgegeben wird. [Pfl98] Abbildung
8.3 zeigt das Schema des Top Down Testings anhand der Modul Hierarchie aus Abbildung
8.1.
Test
A
Abbildung 8.3: Top Down Testing
Test
A, B, C, D
Test
A, B, C, D,
E, F, G
Kapitel 8: Testphase
8.2.3
131
System Testing
Die Aufgaben des System Testings sind unterschiedlich zu den Aufgaben des Unit
Testings und des Integration Testings. Die Ziele des Unit Testings und des Integration
Testings waren sicherzustellen, daß Programmcode geschrieben wurde, der dem Design
des Systems entspricht. Die Phase des System Testings hat ein gänzlich anderes Ziel: In
der Phase des System Testings soll gezeigt werden, daß der implementierte Programmcode
die vom Auftraggeber erwartete Funktionalität korrekt umsetzt. Die Phase des System
Testings besteht aus mehreren Schritten: [Pfl98]

Function Testing

Performance Testing

Acceptance Testing

Installation Testing
Sind die Phasen Unit Testing und Integration Testing abgeschlossen, so wird ein Function
Test durchgeführt. Ein Function Test stellt sicher, daß das System die in den
Systemanforderungen festgelegten Spezifikationen umsetzt. Ab dieser Testphase wird das
System wieder als geschlossenes System betrachtet, d.h. es ist nur ausschlaggebend welche
Funktionalität das System umsetzt, aber nicht wie diese Funktionalität intern repräsentiert
wird. Function Testing basiert auf den funktionalen Systemanforderungen. Jede Funktion
des System kann mit den Modulen, welche diese Funktionalität zur Verfügung stellen
assoziiert werden. Die Menge von Aktionen, die mit einer Funktion verbunden werden,
werden auch als Thread bezeichnet. Daher wird Function Testing auch manchmal als
Thread Testing bezeichnet. [Pfl98]
Wurde durch den Function Test sichergestellt, daß das System die funktionalen
Systemanforderungen korrekt umsetzt, so wird im nächsten Schritt ein Performance Test
durchgeführt. Der Performance Test untersucht das System im Hinblick auf die
nichtfunktionalen Systemanforderungen. Die nichtfunktionalen Systemanforderungen
umfassen global, nicht einer bestimmten Funktion zuzuordnende Eigenschaften wie
Performance, Sicherheit, Benutzerfreundlichkeit, usw. In dieser Phase wird eine Reihe
spezieller Tests durchgeführt, um bestimmte Systemeigenschaften zu testen. Dazu zählen
der Stress Test, in dem das Verhalten des System bei Überlastung getestet wird, ein
Cofiguration Test, indem alle Möglichen Software- und Hardwarekonfigurationen des
Systems getestet werden, der Security Test, um die Sicherheitsanforderungen an das
System zu testen, ein Human Factors Test, um Anforderungen an die Benutzerschnittstelle
des Systems zu testen, usw. [Pfl98]
Hat das System sowohl den Function Test als auch den Performance Test bestanden, so ist
sichergestellt, daß das System sowohl die funktionalen als auch die nichtfunktionalen
Systemanforderungen korrekt umsetzt. [Pfl98]
Im nächsten Schritt erfolgt der Acceptance Test. In diesem Schritt wird das System
gemeinsam mit dem Auftraggeber getestet, um sicherzustellen, daß das entwickelte System
auch das vom Auftraggeber gewünschte System ist. Da dieser Test noch immer in einer
Testumgebung ausgeführt wird, kann ein abschließender Integration Test durchgeführt
werden, der den späteren Benutzern des Systems erlaubt, dieses in der Umgebung zu
testen, in der es später auch eingesetzt werden soll.
Kapitel 8: Testphase
132
Abbildung 8.4 zeigt die Phase des System Testings im Überblick. [Pfl98]
integrierte
Module
funktionale
Systemanforderungen
nichtfunktionale
Systemanforderungen
Auftraggeber
Umgebung
Function
Test
Performance
Test
Acceptance
Test
Installation
Test
funktionsfähiges
System
verifiziertes
System
benutztes
System
akzeptiertes
System
Abbildung 8.4: Die Phase des System Testings im Überblick
In diesem Abschnitt wurden die Aufgaben der Testphase nach dem in Kapitel 2.3
diskutierten Software-Prozeßmodell untersucht. Im nächsten Abschnitt soll konkret auf die
Testphase des in dieser Arbeit entwickelten Projekt zur hierarchischen Benutzerverwaltung
unter Hyperwave eingegangen werden.
8.3 Testphase des Systems zur hierarchischen
Benutzerverwaltung unter Hyperwave
In diesem Kapitel soll die Testphase des in dieser Arbeit beschriebenen Projekts zur
Umsetzung einer hierarchischen Benutzerverwaltung unter Hyperwave besprochen
werden. In der Testphase des Systems zur hierarchischen Benutzerverwaltung unter
Hyperwave sollen folgende Schritte durchgeführt werden:

Unit Testing: Die Funktionalität der zur hierarchischen Benutzerverwaltung
entwickelten Objekte soll getestet werden.

Integration Testing: Die Dialoge und Funktionen zur hierarchischen
Benutzerverwaltung sollen Schrittweise in die Standard-Templates eines Hyperwave
Information Servers 4.1 eingebunden werden.

System Testing: Die Funktionalität des Gesamtsystem wird
zwei Phasen vorgegangen: In Phase eins führt das
hierarchischen Benutzerverwaltung am IICM einen System
testet der Auftraggeber des Systems zur hierarchischen
System.
Im Folgenden soll kurz auf die einzelnen
Benutzerverwaltung eingegangen werden.
überprüft. Dabei wird in
Entwicklungsteam der
Test aus. In Phase zwei
Benutzerverwaltung das
Testphasen
der
hierarchischen
Kapitel 8: Testphase
8.3.1
133
Unit Testing
Um die Funktionalität der Objekte, die für das System zur hierarchischen
Benutzerverwaltung entwickelt wurden, zu testen, soll das Commandline-Tool hwjs (siehe
auch Kapitel 4.8.1) eingesetzt werden. Für jedes Objekt wird ein hwjs-Script erzeugt, das
folgende Funktionalität umsetzt:

Einbinden der benötigten Datenstrukturen und Objekte

Erzeugen einer neuen Instanz des zu testenden Objekts

Testen der Funktionalität des Objekts

Schreiben des Outputs in eine Datei
Beispiel 8.1 zeigt ein hwjs-Script, das die Funktionalität des Objekts hw_UserObject
testet. Zum Test der anderen Objekte wird analog vorgegangen.
include("hwlib/Logfile.js");
include("hwlib/Error.js");
var logFile = new hwlib_Logfile(true,"logfile.txt");
logFile.writeln("********************************************");
var errorObj = new hwlib_Error();
// dummy for language
var session = {language:"en"};
include("hwlib/utils.js");
include("hwlib/hs_lib.js");
include("hwlib/hw_Object.js");
include("hwlib/hw_UserManagementObject.js");
include("hwlib/hw_UserObject.js");
var ni_server = new HW_API_Server("fiicmal05.tu-graz.ac.at");
ni_server.identify({username:"hwtest",password:"XXXXXX"});
// create empty hw_UserObject
logFile.writeln("create empty hw_UserObject");
var user_obj = new hw_UserObject();
// get groups of empty user
logFile.writeln("get groups of empty user");
logFile.writeln("the parents are: "+user_obj.parents());
// create existing hw_UserObject
logFile.writeln("create existing hw_UserObject");
var user_obj = new hw_UserObject("hschwarz");
// get groups of existing user
Kapitel 8: Testphase
134
logFile.writeln("get groups of existing user");
logFile.writeln("the parents are: "+user_obj.parents());
// assign to not existing group
logFile.writeln("assign to not existing group");
user_obj.assignToGroups(Array("dont_exist"));
// assign to existing group
logFile.writeln("assign to existing group");
user_obj.assignToGroups(Array("med"));
// assign again to same group
logFile.writeln("assign again to same group");
user_obj.assignToGroups(Array("med"));
// get groups
logFile.writeln("get groups of existing user");
logFile.writeln("the parents are: "+user_obj.parents());
// remove from not existing group
logFile.writeln("remove from not existing group");
user_obj.removeFromGroups(Array("dont_exist"));
// remove from existing group
logFile.writeln("remove from not existing group");
user_obj.removeFromGroups(Array("med"));
Beispiel 8.1: hwjs Script zum Testen der Funktionalität des hw_UserObject-Objekts
8.3.2
Integration Testing
In der nächsten Testphase sollen die SSJS-Scripts, welche die Dialoge und Funktionen zur
hierarchischen Benutzerverwaltung anbieten, schrittweise in den Hyperwave Server
eingebunden werden. Dabei muß die korrekte Funktionalität jedes einzelnen Scripts
überprüft werden. Dabei soll, wie in Abbildung 8.5 aufgelistet, nach der Bottom-Up
Methode vorgegangen werden.
Kapitel 8: Testphase
1.2.1
dialog.ni_newuser.action
1.1.1
dialog.ni_insertnewuser.action
1.2.2
dialog.ni_listuser.action
1.1.3
dialog.ni_deleteuser.action
1.2.3
dialog.ni_edituser.action
1.1.2
dialog.ni_changeuser.action
2.2.1
dialog.ni_newgroup.action
2.1.1
dialog.ni_insertnewgroup.action
2.2.2
dialog.ni_listgroups.action
2.1.3
dialog.ni_deletegroups.action
2.2.3
dialog.ni_editgroup.action
2.1.2
dialog.ni_changegroup.action
2.2.4
dialog.ni_showgroupmembers.action
3.2.1
dialog.ni_assign_u_g.action
3.1.1
dialog.ni_add_u_g.action
3.1.2
dialog.ni_remove_u_g.action
135
1
Benutzer anlegen,
editieren und löschen
2
Gruppen anlegen,
editieren und löschen
3
Benutzer zu Gruppen
zuordnen
hierarchische
Benutzerverwaltung
Abbildung 8.5: Vorgehensweise zur Integration der Module des Systems zur
hierarchischen Benutzerverwaltung zu einem Gesamtsystem
8.3.3
System Testing
Aufgabe der System Test Phase ist zu testen, ob das Gesamtsystem zur hierarchischen
Benutzerverwaltung unter Hyperwave die in Kapitel 3.4 festgelegten Systemanforderungen
korrekt umsetzt. Dieser Test soll in zwei Schritten erfolgen: Im ersten Schritt soll das
System zur hierarchischen Benutzerverwaltung von der Entwicklungsgruppe am IICM im
Hinblick auf die Umsetzung der funktionalen und nichtfunktionalen Systemanforderungen
getestet werden. Es werden ein Function Test und ein Performance Test durchgeführt. Sind
diese Test erfolgreich abgeschlossen, so erfolgt im zweiten Schritt eine Testphase in der
Systemumgebung des Auftraggebers. Wie zu Beginn des Projekts vereinbart wurde, wird
dieser Test vom Auftraggeber selbst durchgeführt.
Kapitel 8: Testphase
136
8.4 Schlußbemerkung
In diesem Kapitel wurde die Testphase des Projekts „hierarchische Benutzerverwaltung
unter Hyperwave“ untersucht. Aufgabe der Testphase ist, bestehende Fehler aus dem
Programmcode zu entfernen und die korrekte Umsetzung der Systemanforderungen zu
überprüfen. Dabei soll an dieser Stelle nochmals ausdrücklich darauf hingewiesen werden,
daß durch einen Test die korrekte Funktionsweise nicht bewiesen werden kann. Um die
korrekte Funktionsweise einer Funktion zu beweisen, müssen formale Beweismethoden
angewandt werden, die in der vorliegenden Arbeit nicht näher angeführt werden.
Nach Pfleeger [Pfl98] erfolgt die Gliederung der Testphase in drei Teilphasen: In der
Phase Unit Testing werden die einzelnen Module des Systems unabhängig voneinander auf
deren korrekte Funktion geprüft. Nachdem diese Phase abgeschlossen wurde, erfolgt in der
Phase des Integration Testings die koordinierte Integration der einzelnen Module in ein
Gesamtsystem. Dabei kann nach der Methode des Bottom Up Testings oder des Top Down
Testings vorgegangen werden. In der letzten Testphase, dem System Testing wird das
System im Hinblick auf die Anforderungen an das System getestet. In einem Function Test
können die funktionalen Systemanforderungen überprüft werden. Danach erfolgt ein
Performance Test, der die nichtfunktionalen Anforderungen an das System überprüft. Um
festzustellen, ob das Gesamtsystem den Vorstellungen des Auftraggebers entspricht, kann
ein Acceptance Test durchgeführt werden. Da bis zu diesem Zeitpunkt meist in einer
Testumgebung gearbeitet wurde, können in einem letzten Schritt durch einen Integration
Test die Einflüsse der tatsächlichen Systemumgebung auf das fertiggestellte System
getestet werden.
Im Anschluß an die Untersuchung der Aufgaben einer Testphase erfolgte eine
Beschreibung der Testphase des in dieser Arbeit durchgeführten Projekts “hierarchische
Benutzerverwaltung unter Hyperwave“. In der Phase Unit Testing wurden die
Funktionalität der in Abschnitt 6.9 für die Umsetzung eine hierarchischen
Benutzerverwaltung entworfenen Objekte getestet. In der Phase Integration Testing
wurden die einzelnen Module des Systems schrittweise zu einem Gesamtsystem
zusammengesetzt. In der Phase System Testing erfolgte schließlich ein Test des
fertiggestellten Gesamtsystems in Hinblick auf die korrekte Umsetzung der
Systemanforderungen. Am Ende der Phase System Testing wurde schließlich das
Gesamtsystem vom Auftraggeber getestet, um den Einfluß der Umgebung, in der das
System Arbeiten soll festzustellen.
Im folgenden Kapitel, das nach dem in Kapitel 2.3 festgelegten Prozeßmodell der letzten
Phase dieses Projekts entspricht, sollen schließlich die Aufgaben untersucht werden, die
nach der Fertigstellung der in Auftrag gegebenen Software noch durchgeführt werden
müssen, um das System beim Auftraggeber zu integrieren. Dazu zählen vor allem die
Durchführung von Schulungen und das Anbieten von Dokumentationen und Handbüchern
um den Benutzern den Umgang mit dem System zu erleichtern.
Kapitel 9
Integration
9.1 Einleitung
Die Durchführung des Projekts „hierarchische Benutzerverwaltung unter Hyperwave“
befindet sich an dieser Stelle bereits kurz vor dem Abschluß. Die Kapitel 3-8 haben sich
damit beschäftigt, ein System zur hierarchischen Benutzerverwaltung zu definieren, zu
entwerfen, zu implementieren und zu testen. Nach dem Phasenmodell, das zur
Durchführung dieser Arbeit eingesetzte wurde (siehe Kapitel 2.5), ist die Phase der
Integration die letzte Phase in der Projektabwicklung. Die Aufgabe der Integrationsphase
ist, die zukünftigen Benutzer mit dem System vertraut zu machen. Falls die Integration des
Systems fehlschlägt, werden die Benutzer damit nicht zufrieden sein und das System nicht
so gerne und effizient wie möglich benutzen. Die Energie, die in die Entwicklung einer
qualitativ hochwertigen Software gesteckt wurde, ist vergeudet.
In diesem Kapitel soll daher kurz auf die Möglichkeiten eingegangen werden, um eine
erfolgreiche Integration der Software beim Auftraggeber vornehmen zu können. Die zwei
wesentlichen Möglichkeiten, um Software erfolgreich aus dem Bereich der Entwicklung in
den Bereich der Benutzer zu transferieren, sind Schulungen und Dokumentationen. Diese
beiden Möglichkeiten sollen in den folgenden Abschnitten kurz betrachtet werden.
9.2 Schulungen
Grundsätzlich existieren zwei unterschiedliche Typen von Personen, die das System
benutzen werden: Benutzer arbeiten mit dem System, sie setzen die Funktionalität des
Systems ein, um damit Probleme zu lösen. Im Gegensatz dazu sind die Administratoren
des Systems dafür verantwortlich, die Arbeit der Benutzer zu ermöglichen, indem sie das
System warten. Manchmal sind Benutzer und Administrator ein und dieselbe Person.
Kapitel 9: Integration
138
Trotzdem müssen für diese beiden Gruppen von Benutzern zwei verschiedene Arten von
Schulungen eingesetzt werden: [Pfl98]

Benutzerschulungen: Schulungen für Benutzer bauen primär auf den wesentlichen
Funktionen des Systems auf. Gleichzeitig brauchen Benutzer kein Wissen darüber zu
besitzen, wie diese Funktionen intern repräsentiert werden. Benutzer können im
Rahmen der hierarchischen Benutzerverwaltung nach bestimmten Benutzern suchen,
ohne zu wissen welche Suchalgorithmen intern verwendet werden.
Benutzerschulungen vermitteln die grundlegenden Funktionen des Systems, so daß die
Benutzers des Systems diese Funktionen erkennen und einsetzen können.

Administratorschulungen: In Administratorschulungen wird vor allem Kontrolle über
das System vermittelt. Diese Art von Schulung beschäftigt sich primär mit der Frage
„Wie arbeitet das System“ und nicht mit der Frage „Was kann das System“.
Administratoren werden in zwei Bereichen geschult: Erstens lernen Administratoren
das System zu installieren und zu konfigurieren, zweitens lernen administratoren, wie
sie die Benutzer des Systems unterstützen können.
In diesem Abschnitt wurde die Möglichkeit untersucht, Schulungen durchzuführen, um
eine erfolgreiche Integration der Software beim Auftraggeber zu erreichen. Im nächsten
Abschnitt wird auf die Dokumentation von Software eingegangen. Die Dokumentation ist
eine weitere Möglichkeit, um die Integration der Software beim Auftraggeber zu
erleichtern.
9.3 Dokumentation
Die Dokumentation eines Systems ist Teil eines umfassenden Schulungsprogramms. Die
Qualität und Art der Dokumentation kann sich kritisch nicht nur auf die Schulungen,
sondern auch auf den Erfolg des Systems auswirken. Bevor eine Dokumentation erstellt
wird, muß festgestellt werden, für welches Zielpuplikum die Dokumentation gedacht ist.
Es können Dokumentationen und Handbücher für die Benutzer, die Administratoren,
Programmierer oder andere Personen verfaßt werden. Daher werden verschiedene Arten
von Dokumentationen unterschieden: [Pfl98]

Benutzerhandbuch: Ein Benutzerhandbuch ist ein Nachschlagewerk oder eine
Anleitung für gewöhnliche Benutzer des Systems. Dieses Handbuch sollte das gesamte
System in einfachen Worten beschreiben. Die Beschreibung erfolgt meistens in
mehreren Schichten. Diese beginnen mit einer Übersicht über das Systems und enden
mit detaillierten Beschreibungen der einzelnen Funktionen.

Systemhandbuch: Dieses Handbuch beschreibt in ähnlicher Art und Weise wie das
Benutzerhandbuch jene Daten, die für Administratoren von Bedeutung sind. Der
einzige Unterschied zum Benutzerhandbuch ist das Zielpuplikum, das durch das
Systemhandbuch angesprochen wird.

Einführungshandbuch (Tutorial): Manche Benutzer bevorzugen das Erlernen der
Systemfunktionalität anhand von Beispielen. Für diese Benutzer kann ein
Einführungshandbuch verfaßt werden, das an praktischen Beispielen die Funktionalität
des Systems zeigt.
Kapitel 9: Integration

139
Programmierhandbuch: Das Programmierhandbuch beinhaltet eine detaillierte
Auflistung und Beschreibung der internen Module und Funktionalität des Systems. Das
Programmierhandbuch ermöglicht dem Leser in die Funktionalität des Systems
einzugreifen, um Änderungen oder Erweiterungen vorzunehmen.
Im nächsten Abschnitt soll nun kurz auf die Integration des Systems zur hierarchischen
Benutzerverwaltung unter Hyperwave beim Auftraggeber eingegangen werden.
9.4 Integration des Systems zur
hierarchischen Benutzerverwaltung
Nach Vereinbarungen mit dem Auftraggeber für die Entwicklung eines Systems zur
hierarchischen Benutzerverwaltung übernimmt dieser selbst die Einschulung der Benutzer
auf dem in dieser Arbeit entwickelten System. Das Projekt „hierarchische
Benutzerverwaltung unter Hyperwave“ ist daher mit der Auslieferung der Software an den
Auftraggeber abgeschlossen.
9.5 Schlußbemerkung
In diesem Kapitel wurde auf die Integration der fertiggestellten Software beim
Auftraggeber eingegangen. Unter dem Begriff „Integration“ muß in diesem
Zusammenhang das Vertraut machen der zukünftigen Benutzer mit dem System
verstanden werden. Die wichtigsten Möglichkeiten, um eine erfolgreiche Integration beim
Auftraggeber vornehmen zu können, sind das durchführen Schulungen und das Anbieten
von Dokumentationen und Handbüchern zu dem vorliegenden System. Sowohl bei
Durchführung von Schulungen als auch bei der Erstellung von Handbüchern muß auf die
Zielgruppe, für das Handbuch bzw. die Schulung bestimmt ist, geachtet werden. Es muß
zwischen Benutzern, Administratoren und Programmierern unterschieden werden. Jede
dieser Gruppen erfordert individuelle Schulungen und eigene Handbücher.
Mit diesem Kapitel ist die Umsetzung des Projekts „hierarchische Benutzerverwaltung
unter Hyperwave“ nach dem in Kapitel 2.5.3 festgelegten Projektplan beendet. Im
folgenden Kapitel dieser Arbeit soll noch auf Perspektiven und Aussichten zur
Weiterentwicklung eines Systems zur hierarchischen Benutzerverwaltung unter
Hyperwave eingegangen werden, bevor im letzten Kapitel der vorliegenden Arbeit deren
Ablauf und Durchführung nochmals zusammengefaßt wird.
Kapitel 10
Ausblick
Das in dieser Arbeit entwickelte System einer hierarchischen Benutzerverwaltung wurde
möglichst modular aufgebaut, um dessen Funktionalität einfach erweitern und verbessern
zu können. An dieser Stelle sollen einige Ideen aufgezeigt werden, um das System zur
hierarchischen Benutzerverwaltung unter Hyperwave weiterzuentwickeln:

Ein Ansatz der weiterverfolgt werden kann ist die Erweiterung des Systems zur
hierarchischen Benutzerverwaltung um eine Zugriffskontrolle. Dieses in Kapitel 5.1.2
erläuterte Prinzip würde bedeuten, daß bei der Vergabe von Zugriffsrechten
automatisch alle im Sinne der hierarchischen Benutzerverwaltung übergeordneten
Benutzer ebenfalls Zugriff auf das entsprechende Dokument erhalten.

In einer weiteren Entwicklungsstufe kann das System zur hierarchischen
Benutzerverwaltung um eine grafische Benutzerschnittstelle erweitert werden. Mit
Hilfe dieser Benutzerschnittstelle kann die hierarchische Anordnung der Benutzer
optisch dargestellt werden. Neue Benutzer können einer bestimmten Hierarchiestufe
durch einen einfachen Mausklick zugeordnet werden. Das grafische Benutzerinterface
kann auch die Möglichkeiten bieten, ganze Teilhierarchien der Benutzerhierarchie zu
verschieben.

Die hierarchische Benutzerverwaltung könnte in das neue Modulkonzept des während
der Durchführung der vorliegenden Arbeit erschienenen Hyperwave Information
Server 5.0 integriert werden.
Eine weitere Möglichkeit die sich anbietet, um ein System zur hierarchischen
Benutzerverwaltung in Hyperwave zu integrieren ist, wie in Kapitel 5.1.2 bereits
angesprochen wurde, das System in den Kernel des Hyperwave Information Servers
einzubinden. Diese Möglichkeit wäre mit Sicherheit die letztendlich anzustrebende
Variante, um ein System zur hierarchischen Benutzerverwaltung dauerhaft in den
Hyperwave Information Server zu integrieren. Da diese Möglichkeit aber mit großen
finanziellen und technischen Aufwendungen verbunden wäre, müßte zuvor genau
überprüft werden, ob ein Bedarf an einer hierarchischen Benutzerverwaltung auch in
anderen Hyperwave-Systemen besteht.
Kapitel 11
Zusammenfassung
In den letzten Jahren werden zunehmend auf der Technologie des Internets aufbauende
Systeme eingesetzt, um auch firmenintern Informationen für Mitarbeiter anzubieten. Kern
dieser Intranetlösungen sind sogenannte Information Server, die eine Vielzahl von
Möglichkeiten anbieten, um Informationen zu verwalten. Bestimmte Benutzergruppen
können als Autoren agieren, um neue Dokumente auf dem Server zu erstellen, während
andere Benutzer nur lesend auf diese Dokumente zugreifen dürfen. Um einem Benutzer
das Recht geben zu können, Dokumente am Server einzufügen, zu ändern oder zu löschen,
muß sich dieser am System identifizieren. Erst nach erfolgter Identifikation kann dem
Benutzer das Verändern der Dokumente am Server erlaubt werden. Die Daten, die zur
Identifikation der Benutzer benötigt werden, müssen von den Systemadministratoren des
Servers verwaltet werden. Nur diese dürfen neue Benutzer erzeugen, Benutzerdaten ändern
und Benutzer wieder aus dem System löschen.
Wird in einem System eine sehr große Anzahl von Benutzern administriert, so entsteht
durch die Aufgaben der Benutzerverwaltung eine zusätzliche, nicht unwesentliche
Belastung der Systemadministratoren. In der vorliegenden Arbeit soll daher ein System zur
hierarchischen Benutzerverwaltung entwickelt werden, um die Benutzeradministration aus
dem Aufgabenbereich der Systemadministratoren loszulösen. Werden gewisse
Vorkehrungen getroffen, so kann auch Benutzern ohne Systemrechte das Recht gegeben
werden neue Benutzer im System anzulegen.
Das auszuarbeitende System soll einer neuen Gruppe von Benutzern, des sog.
Projektadministratoren ermöglichen, neue Benutzer zu erzeugen. Um zu verhindern, daß
die Projektadministratoren ihre Kompetenzen überschreiten und andere Benutzer aus dem
System löschen, werden den Projektadministratoren hierarchisch angeordnete
Zuständigkeitsbereiche zugeteilt. Projektadministratoren dürfen nur in ihren
Zuständigkeitsbereichen neue Benutzer anlegen, editieren und löschen. An der Spitze
dieses hierarchischen Systems schließlich steht ein Projektadministrator, der auf alle
Benutzer Zugriff hat.
Um die Qualität und den Erfolg des in dieser Arbeit beschriebenen Projekts „hierarchische
Benutzerverwaltung unter Hyperwave“ zu gewährleisten, wurde das Projekt in Kapitel 2
nach den Methoden des Projektmanagements geplant. Die vorliegende Arbeit orientiert
sich dabei an der Methode nach Pfleeger. [Pfl98] Die Durchführung der vorliegenden
Arbeit gliedert sich in zwei Bereiche.
Kapitel 11: Zusammenfassung
142
Ziel des ersten Bereichs dieser Arbeit, dem Untersuchungsbereich, ist es, ein konkretes
Konzept zur Umsetzung einer hierarchischen Benutzerverwaltung unter Hyperwave
abzuleiten. Im ersten Schritt des Untersuchungsbereichs werden daher die Anforderungen
an ein System zur hierarchischen Benutzerverwaltung untersucht (siehe Kapitel 3).
Nachdem die Anforderungen an das System festgelegt wurden, werden in Kapitel 4 die
Eigenschaften des Hyperwave Information Servers untersucht, in den das System zur
hierarchischen Benutzerverwaltung eingebunden werden soll. In Kapitel 5 werden
schließlich bereits bestehende Lösungen im Hinblick auf eine hierarchische
Benutzerverwaltung analysiert und eigene Konzepte zur Umsetzung einer hierarchischen
Benutzerverwaltung entwickelt. Diese Möglichkeiten werden diskutiert und bewertet, um
schließlich am Ende des Untersuchungsbereiches ein konkretes Konzept zur Umsetzung
einer hierarchischen Benutzerverwaltung unter Hyperwave ableiten zu können (siehe
Kapitel 5.2).
Im zweiten Bereich der vorliegenden Arbeit, dem Gestaltungsbereich, soll das im
Untersuchungsbereich ausgewählte Konzept zur Umsetzung einer hierarchischen
Benutzerverwaltung in die Funktionalität eines Hyperwave Information Servers 4.1
eingebunden werden. In Kapitel 6 wird die technische Entwicklung des Systems
durchgeführt. Dabei wird nach den Methoden des OOD vorgegangen, um ein modulares,
wiedereinsetzbares und einfach zu wartendes System zu entwickeln. Nachdem in Kapitel 7
auf die Programmierrichtlinien zur Umsetzung eines Systems zur hierarchischen
Benutzerverwaltung eingegangen wurde, wird das System tatsächlich implementiert. In der
anschließenden Testphase (siehe Kapitel 8), muß die korrekte und fehlerfreie Umsetzung
der in Kapitel 3.4 festgelegten Anforderungen an ein System zur hierarchischen
Benutzerverwaltung überprüft werden. In Kapitel 9 dieser Arbeit wird in der
Integrationsphase schließlich noch auf Maßnahmen eingegangen, die getroffen werden
müssen, um die fertiggestellte Software beim Auftraggeber erfolgreich integrieren zu
können. Die Integrationsphase bildet nach den in Kapitel 2 untersuchten Methoden des
Projektmanagements die letzte Phase im Ablauf eines Projekts.
Anhang 1
Abbildungsverzeichnis
Abbildung 2.1: Das Wasserfall-Modell beschreibt den Software-Entwicklungsprozeß als
eine Kette von abgeschlossenen Teilprozessen. [Pfl98] .................................... 7
Abbildung 2.2: Das V-Modell erzeugt Beziehungen zwischen den einzelnen Entwicklungsund Testphasen. [Pfl98]...................................................................................... 8
Abbildung 2.3: Das Prototyping-Modell verwendet den Prozeß des Prototypings, um den
Software-Entwicklungsprozeß zu beschreiben. [Pfl98] ..................................... 8
Abbildung 2.4: Das Spiral-Modell stellt den Software-Entwicklungsprozeß in Form von
Entwicklungszyklen dar. [Pfl98] ........................................................................ 9
Abbildung 2.5: Der Projektplan des Projekts „hierarchische Benutzerverwaltung unter
Hyperwave“ ...................................................................................................... 18
Abbildung 4.1: Attribute eines HTML-Dokuments auf einem Hyperwave Server ............ 33
Abbildung 4.2: Collections sind Contianerobjekte für beliebige Objekte. [Mau96]........... 34
Abbildung 4.3: Eine Sequence definiert einer Reihenfolge auf ihren Inhalt. [Mau96]....... 35
Abbildung 4.4:Benutzerdaten werden von Hyperwave ebenfalls als Objekte behandelt.... 36
Abbildung 4.5: Die Architektur des Hyperwave Information Servers [Mau96] ................. 39
Abbildung 4.6: Ansicht eines Collection-Listings, wie es vom Wavemaster dargestellt
wird................................................................................................................... 41
Abbildung 4.7: Der Server erkennt den CGI-Aufruf und startet die entsprechende
Applikation. [SQ98] ......................................................................................... 51
Abbildung 4.8: Attribute eines CGI-Objektes ..................................................................... 51
Abbildung 5.1: Die Hierarchiestufe auf der sich ein Benutzer befindet, wird in dem
Attribut InfoSpace des Benutzerobjekts festgehalten. ................................. 61
Abbildung 5.2: Eine Informationsraum-Hierarchie kann auch aus speziellen
Gruppenobjekte aufgebaut werden................................................................... 62
Abbildung 5.3: Auch die Eltern einer Gruppe dürfen auf das Objekt zugreifen. ................ 63
Abbildung 6.1: Event-Diagramm der Funktionsgruppe „Benutzer anlegen, editieren und
löschen“ ............................................................................................................ 72
Abbildung 6.2: Das Event-Diagramm der Funktionsgruppe „Gruppen anlegen, editieren
und löschen“ besitzt den zusätzlichen Dialog „Benutzer auflisten“ ................ 73
Abbildungsverzeichnis
144
Abbildung 6.3: Eventdiagramm der Funktionsgruppe „Benutzer zu Gruppen zuordnen“.. 74
Abbildung 6.4: Die Funktionsgruppe „Benutzer anlegen, editieren und löschen“ wird im
Rahmen der hierarchischen Benutzerverwaltung um eine Suchfunktion
erweitert. ........................................................................................................... 75
Abbildung 6.5: Die Funktionsgruppe „Gruppen anlegen, editieren und löschen“ im
Rahmen der hierarchischen Benutzerverwaltung ............................................. 77
Abbildung 6.6: Event-Diagramm der Funktionsgruppe „Benutzer zu Gruppen zuordnen“ 78
Abbildung 6.7: Der Standard-Dialog zum Anlegen eines neuen Benutzers. ...................... 80
Abbildung 6.8: Der „neuer Benutzer“-Dialog für die hierarchische Benutzerverwaltung.. 81
Abbildung 6.9: Der „Benutzer anzeigen“-Dialog wird um eine Suchfunktion erweitert. ... 82
Abbildung 6.10: Anhand dieser einfachen Objekthierarchie soll objektorientiertes
Programmieren unter JavaScript veranschaulicht werden. [JSO99] ................ 86
Abbildung 6.11: Nachdem Objekte definiert wurden, können Instanzen dieser Objekte mit
dem new-Operator erzeugt werden. [JSO99] ................................................... 88
Abbildung 6.12: Die Objekthierarchie der in hwlib verfügbaren Objekte [Hwl99] ......... 89
Abbildung 6.13: Die Objekthierarchie im Überblick ........................................................ 100
Abbildung 6.14: Die Dateistruktur der hierarchischen Benutzerverwaltung .................... 114
Abbildung 7.1: Arbeitsweise mit dem Hyperwave Information Server zur Implementierung
eines Systems zur hierarchischen Benutzerverwaltung. ................................ 121
Abbildung 8.1: Beispiel für eine Hierarchie von Modulen in einem System [Pfl98] ....... 130
Abbildung 8.2: Bottom Up Testing [Pfl98] ....................................................................... 130
Abbildung 8.3: Top Down Testing [Pfl98] ....................................................................... 130
Abbildung 8.4: Die Phase des System Testings im Überblick [Pfl98].............................. 132
Abbildung 8.5: Vorgehensweise zur Integration der Module des Systems zur
hierarchischen Benutzerverwaltung zu einem Gesamtsystem ....................... 135
Tabellenverzeichnis
Tabelle 1.1: Typografische Vereinbarungen ......................................................................... 3
Tabelle 1.2: Ursachen für gescheiterte Projekte [Sta94] ....................................................... 4
Tabelle 2.1: Projektphasen für das Projekt „Hierarchische Benutzerverwaltung unter
Hyperwave“ ...................................................................................................... 13
Tabelle 2.2: Aufwandsabschätzung für das Projekt „hierarchische Benutzerverwaltung
unter Hyperwave“. ........................................................................................... 14
Tabelle 2.3: Aufwandsabschätzung der Teilprozesse in der Analysephase. ....................... 14
Tabelle 2.4: Aufwandsabschätzung der Teilprozesse in der Designphase. ......................... 15
Tabelle 2.5: Aufwandsabschätzung der Teilprozesse in der Testphase. ............................. 15
Tabelle 2.6: Aufwandsabschätzung der Teilprozesse in der Abnahmephase. ..................... 16
Tabelle 2.7: Meilensteine des vorliegenden Projekts .......................................................... 16
Tabelle 2.8: Die AOB bestimmen die Nachfolger jeder einzelnen Projektphase. .............. 17
Tabelle 3.1: Attribute, die Benutzerobjekte im Netinfo-System besitzen können. ............. 26
Tabelle 3.2: Auch Gruppenobjekte werden in die hierarchische Benutzerverwaltung
eingebunden. .................................................................................................... 27
Tabelle 4.1: Vordefinierte Objekte in HWJS [HwP98]....................................................... 47
Tabelle 4.2: Vordefinierte Objekte, auf die über die Wavemaster-Templates zugegriffen
werden kann. [HwP98] ..................................................................................... 49
Tabelle 5.1: UIDs für System-Accounts unter UNIX [UX99] ............................................ 56
Tabelle 5.2: Kriterien, um ein geeignetes Konzept zur Umsetzung einer hierarchischen
Benutzerverwaltung unter Hyperwave zu auszuwählen. ................................. 66
Tabelle 6.1: Jede ausführbare Aktion wird einer eigenen Server-Action zugeordnet. ........ 76
Tabelle 6.2: Für die Funktionsgruppe „Gruppen anlegen, editieren und löschen“ werden
sieben Server-Actions definiert. ....................................................................... 78
Tabelle 6.3: Für die Funktionsgruppe „Benutzer zu Gruppen zuordnen werden drei neue
PLACE-acions definiert. .................................................................................. 79
Tabelle 6.4: Die Server-Actions und dazugehörigen Macros der hierarchischen
Benutzerverwaltung. ........................................................................................ 84
Tabelle 6.5: Das Employee Objekt und die Klasse Employee [JSO99] ......................... 86
Tabelle 6.6: Manager und WorkerBee werden vom Employee abgeleitet. [JSO99] .... 87
Tabelle 6.7: Die Definitionen für SalesPerson und Engineer. [JSO99] .................... 87
Tabelle 6.8: Methoden, die von hw_UserObject überschrieben werden. ....................... 95
Tabellenverzeichnis
146
Tabelle 6.9: Neue Methoden des hw_UserObjects ........................................................ 95
Tabelle 6.10: Die Klasse hw_UserObjectDecorator implementiert die Funktionen
zum Anzeigen der Dialoge ............................................................................... 96
Tabelle 6.11: Methoden, die von hw_GroupObject überschrieben werden.................... 96
Tabelle 6.12: Neue Methoden des hw_GroupObjects.................................................... 97
Tabelle 6.13: Die Klasse hw_GroupObjectDecorator implementiert die Funktionen
zum Anzeigen der Dialoge. Eine genaue Beschreibung dieser Methoden erfolgt
in Kapitel 6.9.4. ................................................................................................ 97
Tabelle 6.14: Methoden der Server-Klasse ......................................................................... 99
Tabelle 6.15: Methoden von hw_UserManagementObject ........................................ 101
Tabelle 6.16: Methoden von hw_UserObject ............................................................... 103
Tabelle 6.17: Methoden des hw_GroupObject ............................................................. 104
Tabelle 6.18: Methoden des hs_lib_Server-Objekts .................................................. 106
Tabelle 6.19: Methoden des hw_UserObjectDecorator-Objekts ............................. 110
Tabelle 6.20: Methoden des hw_GroupObjectDecorator-Objekts ........................... 112
Tabelle 6.21: Aufwandsabschätzung der Teilprozesse in der Implementierungsphase. ... 117
Tabelle 11.1: Gebräuchliche Abkürzungen, die in dieser Arbeit verwendet werden. ....... 147
Abkürzungsverzeichnis
Abkürzung
Bedeutung
ASCII
American Standard Code for Information Interchange
HTML
Hypertext Markup Language
hwlib
Hyperwave Libary
OOA
Objektorientierte Analyse
OOD
Objektorientiertes Design
OOP
Objektorientiertes Programmieren
SSJS
Serverside JavaScript
WWW
World Wide Web
Tabelle 11.1: Gebräuchliche Abkürzungen, die in dieser Arbeit verwendet werden.
Literaturverzeichnis
[Boo92]
Booch, Gardy: Object Oriented Design with Applications. California:
Benjamin/Cummings Publishing, 1992
[CO99]
COCOMO: Constructive Cost Modelling. Online im Internet: URL:
http://sunset.usc.edu/COCOMOII/cocomo.html [Stand 15.10.99]
[CRC99]
Beck, Kent: A Laboratory For Teaching Object-Oriented Thinking. Online im
Internet: URL: http://c2.com/doc/oopsla89/paper.html [Stand 15.10.99]
[DH96]
Dalitz ,W.; Heyer, G.: Hyperwave: The Next Generation Internet Information
System.. Heidelberg: dpunkt Verl., 1996
[FLA98]
Flanagan D.: JavaScript: The Definitive Guide. Sebastopol: O’Reilly &
Associates, 1998
[FME99]
o.V.: Formal Methods Europe. Online im Internet: URL:
http://www.cs.tcd.ie/FME/ [Stand 15.10.99]
[FP99]
IFPUG: International Function Point Users Group. Online im Internet: URL:
http://www.bannister.com/ifpug/home/docs/ifpughome.html [Stand 15.10.99]
[HwA98]
o.V.: Hyperwave Administration Guide. USA: Hyperwave Information
Management Inc., 1998
[Hwl99]
Wurzenberger, Georg: hwlib Reference Guide. Online im Internet: URL:
http://www2.iicm.edu/cguetl/education/projects/gwurze/hw_main.ps
[Stand 15.10.99]
[HwP98]
o.V.: Hyperwave Programmer's Guide. USA: Hyperwave Information
Management Inc., 1998
[HwU98]
o.V.: Hyperwave User's Guide. USA: Hyperwave Information Management
Inc., 1998
[ICT98]
OCDE: Use of information and communication technologies at work. Online
im Internet: URL: http://www.oecd.org/dsti/sti/it/infosoc/prod/ICTWORK.pdf
[Stand 15.10.99]
[Inf99]
o.V.: Informix Guide to SQL: Syntax. Online im Internet: URL:
http://www.informix.com/answers/english/docs/912ius/3878.pdf
[Stand 15.10.99]
[IT98]
OCDE: Use of Information Networks and their Impact on Organisational
Structures. Online im Internet: URL: http://www.oecd.org/dsti/sti/it/stats
/itout-2.pdf [Stand 15.10.99]
[JSO99]
o.V.: Object Hierarchy and Inheritance in JavaScript. Online im Internet:
URL: http://developer.netscape.com/docs/manuals/communicator/jsobj
/contents.htm [Stand 15.10.99]
Literaturverzeichnis
149
[Mab96]
Maubach, Claudia u.a.: Windows NT 4 intern. 1. Auflage Data Becker, 1996
[Mau96]
Maurer, Hermann: Hyper-G now Hyperwave: The next generation web
solution. England: Addison Welsley Longman, 1996
[MR97]
Mergit, Ashley; Ritchey, Timothy: WindowsNT User Administration. 1.
Auflage Sebastobol: O'Reilly & Associates Inc., 1997
[NPT99]
o.V.: Die Zeitplanung mit Hilfe der Netzplantechnik. Online im Internet:
URL: http://www.inf-wiss.uni-konstanz.de/CURR/winter96/betrieb
/std10a.html [Stand 15.10.99]
[Pfl98]
Pfleger, Shari: Software Engeneering. USA: Prentice-Hall Inc.,1998
[PLA99]
o.V.: Hyperwave PLACE Workshop. Online im Internet: URL:
http://195.180.244.180/publish/downloads/placewse.pdf [Stand 15.10.99]
[SQ98]
Spanhour, S.; Quercia, V.: Webmaster in a Nutshell. Sebastopol: O’Reilly &
Associates, 1996
[STA94]
The Standish Group: CHAOS. Online im Internet: URL:
http://www.standishgroup.com/chaos.html [Stand 15.10.99]
[UX99]
Indiana University: Unix Workstation Administration Tasks: Users, Groups
and Passwords. Online im Internet: URL: http://www.uwsg.indiana.edu/usail/
tasks/users-groups/users-groups.html [Stand 15.10.99]
[Zit99]
Bleuel, Jens: Zitieren von Quellen im Internet. Online im Internet: URL:
http://www.uni-mainz.de/~bleuj000/zitl.html [Stand 15.10.99]
Anhang 2
CD-ROM
Inhalt:
Referenzen, soweit in elektronischer Form verfügbar
Vorliegende Arbeit
Sourcecode