Extracto
Gerhard-Mercator-Universität Duisburg
Fakultät 4 für Naturwissenschaften
Aufgabenstellung und Betreuung:
Datum: 20. Mai 2002
Realisierung einer Website auf
der Basis eines UML-Entwurfes
am Beispiel einer Materialsammlung aus Informatik und Mathematik
Diplomarbeit DI
vorgelegt von Maria Oelinger
Realisierung einer Website auf der Basis eines UML-Entwurfes
2
VORWORT
An die LeserInnen
Wer die Ergebnisse aus dieser Arbeit als hilfreich empfindet, sollte an die
vielen netten Leute denken, die dazu einen Beitrag leisteten. Durch persönliche
Anmerkungen, konstruktive Kritik, spontanes Feedback und die
Praxiserfahrungen während der Projekte mit KollegInnen konnte diese
Diplomarbeit erst entstehen.
Universität
Duisburg
Zunächst danke ich Prof. Dr. Hoppe für seine wertvollen Hinweise und
Ratschläge während der Bearbeitung des Themas. Er hatte immer ein offenes
Ohr für Fragen und Probleme, was zur Qualität dieser Arbeit wesentlich
beigetragen hat. Die anderen Dozenten der Informatik haben mich mit ihren
Vorlesungen vom ersten Semester an für dieses Fach begeistert und weckten
mein Interesse für Datenbanken. Die MitarbeiterInnen des Fachbereichs
Informatik diskutierten mit mir und hinterfragten kritisch die einzelnen
Funktionalitäten der Website.
Ressourcen
Martin Gerardi und Dirk Holtwick von der spirito GmbH Duisburg danke ich
dafür, dass sie mir den Dado Web Application Server und den Webspace zur
Verfügung stellen. Sie nahmen sich ausgiebig Zeit, mir meine Fragen zu
beantworten. Die MitarbeiterInnen von spirito gaben mir Anregungen und
ließen mich die Site in ihren Browsern testen. Viele Ideen konnten so während
fachlicher Diskussionen entstehen.
Materialien für die
Fachinhalte
Patricia Jung stellt mir den Linux-Kurs zu Verfügung. Andrea Heck von der
AFRA GmbH überlässt mir das Skript zum Testmanagement zur
Veröffentlichung. Alexander Barth von TIME'S UP erlaubt mir, das Skript zum
interaktiven Environment Body Spin zu publizieren. KommilitonInnen tragen
mit Seminarunterlagen und Prüfungsprotokollen zur Materialsammlung bei.
Informatik-
netzwerk
Ein Dankeschön an die Ladies: Zuerst an Veronika Oechtering, die die
Informatica Feminale in Bremen organisiert. Dort begann meine Themensuche.
Dann danke ich Brigitte Jellinek, die mich heftig mit dem Informatik-Virus
infizierte. Meine Mentorin Dr. Angelika Lukat von der Fraunhofer Gesellschaft
hat mich bei der leidigen Themensuche ermuntert und mich mit ihren
Erfahrungen unterstützt. Barbara Roth vom Mentoringprojekt MUFFIN 21 hat
sich als strenge Korrekteurin dieser Arbeit verdient gemacht. Außerdem
gehören unbedingt noch hierher: Die Mädels vom admin@-Projekt (Universität
Hamburg), die mich in die Geheimnisse von UML einweihten, nämlich Heike
Wagner, Beate Orlowski und Irina L. Marinescu.
Unterstützung
Mein Bruder Georg hat mir damals meinen ersten Rechner geschenkt. Mit ihm
kann ich über Bits, Bytes und Bugs diskutieren. Er hat im Verlauf der
Realisation konstruktiv die Website kritisiert und sie getestet.
Besonderen Dank verdient sich mein Lebensgefährte Sven, der meine
gelegentliche Frustration aus nächster Nähe ertragen musste und trotzdem
immer davon überzeugt war, dass diese Arbeit einmal fertig sein wird ...
Realisierung einer Website auf der Basis eines UML-Entwurfes
3
Inhaltsverzeichnis
Vorwort
2
Inhaltsverzeichnis
3
Abbildungsverzeichnis
6
Tabellenverzeichnis
7
Abkürzungen
8
1. Einleitung
9
1.1 Motivation
9
1.1.1 Geschichte des WWW
9
1.1.2 Schlechte und gute Beispiele für Websites
13
1.2 Vorgehensweise
21
1.3 Problembeschreibung
22
2. Anforderungen
25
2.1 Anforderungen und Skalierbarkeit
25
2.1.1
Templates
25
2.1.2 Flexibel erweiterbare Struktur
26
2.1.3 Erstellung und Pflege
27
2.2 Analyse
28
2.2.1 Übersicht über die Bereiche
28
2.2.2 Übersicht über die Fachgebiete
28
2.2.3 Übersicht über die Dateien
29
2.3 Theoretische Grundlage: UML
29
3. Funktionalität
30
3.1 UML-Diagramme
30
3.1.1 Welche Funktionen können mit welchen Diagrammen dargestellt werden?
30
3.1.2
Use-Case-Diagramme
31
3.1.3
Klassendiagramme
34
3.1.4
Sequenzdiagramme
36
3.1.5
Zustandsdiagramm
37
3.1.6 Bewertung und Begründung der Auswahl
38
Realisierung einer Website auf der Basis eines UML-Entwurfes
4
3.2 Metadaten Möglichkeiten des Findens
39
3.2.1 Dublin-Core-Standard und Metadatenklassifizierung
39
3.2.2 XMI XML Metadata Interchange
41
3.2.3 Metatags in HTML
42
3.2.4
Weitere
Formate
43
3.2.5 Bewertung und Auswahl
44
3.3 Datenbank und Web Application Server
45
3.3.1
DB-Anbindung
45
3.3.2
Ausgabeinterface
45
3.3.3 Admininterface: Änderungs- und Eingabeinterface
46
3.3.4
Siteadmininterface
49
3.3.5 Siteweites Suchen und Finden
50
3.3.6 Suchergebnisse sammeln
50
3.4 Machbarkeit
50
4. Konzept und Umsetzung
53
4.1 Szenarien
53
4.2 Strukturierungsmöglichkeiten
54
4.2.1
Indexierung
54
4.2.2
Suche
54
4.3 Basissoftware
55
4.3.1 Software für Redakteure
55
4.3.2 Software für Webdesigner
56
4.3.3 Software für Entwickler und Programmierer
58
4.3.4 Software für den Besucher
59
4.4 Dateiformate und ihre Aufgaben
60
4.4.1 Design, Entwicklung und Realisierung
60
4.4.2
Redaktion
63
4.5 Layout und Design
64
Realisierung einer Website auf der Basis eines UML-Entwurfes
5
5. Realisierung und Dokumentation
67
5.1 Sitestruktur und Inhaltsübersicht
68
5.2 Datenbankstruktur
71
5.3 Funktion und Besonderheiten des Web Application Servers
72
5.4 Styleguide
74
5.5 HTML-Seiten
79
5.6 Datenimport
80
5.6.1 Zugriff gewähren
80
5.6.2 Konvertierung der vorhandenen Materialien
82
6. Fazit
84
6.1 Zusammenfassung
84
6.2 Ausblick
84
6.3 Zukunftstrends
85
Anhang
87
A. Quellenverzeichnis
88
B. Materialien
95
C. Dado-Befehlsverzeichnis
100
D. Datenbankstruktur
110
E. Browser-Screenshots
115
F. Glossar
121
Realisierung einer Website auf der Basis eines UML-Entwurfes
6
Abbildungsverzeichnis
Abb. 1.1
Lynx ein textbasierter Browser
10
Abb. 1.2
Aufbau des URL
12
Abb. 1.3
Fehlendes Bild und unbeabsichtigte Hintergrundkachelung
14
Abb. 1.4
Schlichte Startseite
15
Abb. 1.5
Fehlerhafte Darstellung in Opera
16
Abb. 1.6
Farbige Texte sind keine Links
16
Abb. 1.7
Farbige Texte sind Links
17
Abb. 1.8
Redundanz für verschiedene Wahrnehmungstypen
17
Abb. 1.9
Animiertes Steinschlag-Schild
18
Abb. 1.10
Feature Druckversion
19
Abb. 1.11
URL-Angabe: So findet man die Seite leicht wieder
19
Abb. 1.12
Der Besucher kann selbst entscheiden, ob die Information für ihn aktuell ist
20
Abb. 3.1
Use-Case-Diagramm "Engineering"
31
Abb. 3.2
Use-Case-Diagramm "Content"
32
Abb. 3.3
Use-Case-Diagramm "Schnittstelle zwischen Content und Engineering"
33
Abb. 3.4
Klassendiagramm "Interfaces" Komponenten
34
Abb. 3.5
Klassendiagramm "Materials"
35
Abb. 3.6
Sequenzdiagramm "Edit content"
36
Abb. 3.7
Sequenzdiagramm "Search"
37
Abb. 3.8
Zustandsdiagramm "Search"
38
Abb. 3.9
MCF-Screenshot: 3D-Darstellung von Webinhalt
44
Abb. 3.10
Screenshot der Seite "Skript" in der Ausgabeansicht
46
Abb. 3.11
Editiersymbol im Admininterface
46
Abb. 3.12
Screenshot der Seite "Skript" in der Änderungsansicht
47
Abb. 3.13
Screenshot zur Änderung der Metadaten
48
Abb. 3.14
Screenshot der Datenbanktabelle "dictionary_en2de" für das Wörterbuch
49
Abb. 4.1
Anti-Alias-Effekt
62
Abb. 4.2
jpg-Artefakte
62
Abb. 4.3
Seite "Quellenverzeichnis" mit Fußzeile
64
Abb. 4.4
Design einer Skriptseite
65
Abb. 4.5
Farbwechsel im Design?
66
Abb. 5.1
Unsichtbarer Aufbau der Sitemap
70
Abb. 5.2
Grobe Skizze für das neue Design
74
Abb. 5.3
Banner der Website
77
Abb. 5.4
Zuordnung der Einträge aus der Textdatei zu den Tabellenfeldern der DB
83
Realisierung einer Website auf der Basis eines UML-Entwurfes
7
Tabellenverzeichnis
Tabelle 1.1
Browser im Jahr 2002 (nicht vollständig)
11
Tabelle 1.2
Generic-Top-Level-Domains
12
Tabelle 3.1
Machbarkeitsübersicht
50
Tabelle 5.1
Ordnerstruktur
69
Tabelle 5.2
Farben der Website
75
Tabelle 5.3
Grafiken zur Navigation
75
Tabelle 5.4
Grafiken zu Grundfunktionen und für das Layout
76
Tabelle 5.5
Grafiken zur Interaktion
76
Tabelle 5.6
Symbole im Admininterface
77
Tabelle 5.7
Style Sheets für die Online-Ausgabe
78
Tabelle 5.8
Style Sheets für die Druckversion
78
Tabelle 5.9
Zugriffsrechte
80
Tabelle 5.10
Benutzer und Gruppen
81
Tabelle 5.11
Gruppen und Verzeichnisse
81
Realisierung einer Website auf der Basis eines UML-Entwurfes
8
Abkürzungen
Abb. Abbildung
bzw. beziehungsweise
d. h.
das heißt
d. i.
das ist
Dado
Dado Application Server
DB Datenbank
engl. englisch
etc. et
cetera
evtl. eventuell
f folgende
ff (mehrere)
folgende
i. a.
im Allgemeinen
i. d. R.
in der Regel
kB Kilobyte
o. ä.
oder ähnliches
S. Seite
s. siehe
Tab. Tabelle
u. a.
und andere, unter anderem
usw.
und so weiter
vgl. vergleiche
vs.
versus (im Gegensatz zu)
z. B.
zum Beispiel
z. Zt.
zur Zeit
Realisierung einer Website auf der Basis eines UML-Entwurfes
9
1. EINLEITUNG
1.1 Motivation
Ziel der Arbeit
Die vorliegende Arbeit befasst sich mit dem Problem, Lehrmaterialien über das
WWW zu publizieren. Die Materialien stammen aus den Bereichen
Mathematik, Informatik und Kunst. Die Materialsammlung besteht bereits in
Form eines statischen Webangebotes, das im Rahmen dieser Arbeit als
Grundlage dient. Eine Dynamisierung soll den weiteren Ausbau der Sammlung
erleichtern. Mittels Datenbankanbindung und Web Application Server wird
eine dynamische Website erreicht. Die Besucher sollen Inhalte einfach und
schnell finden. Einige komfortable Zusatzfunktionen können die Akzeptanz der
Website erhöhen. Um ein Bild möglicher Funktionen zu erhalten, werden
zunächst die Geschichte des World Wide Web und einige Websites dargestellt.
1.1.1
Geschichte des WWW
Leben mit dem
WWW
Das World Wide Web ist mittlerweile selbstverständlich Teil unseres Lebens
geworden. Es verbindet die ganze Welt miteinander und macht den Austausch
von Informationen zu einem Kinderspiel. Die über das WWW bequem
erreichbaren Informationen erleichtern das tägliche Leben. Zum Beispiel spart
man durch Routenplanung, Fahrplaninformationen, den Online-Service von
Bibliotheken und anderes wirklich viel Zeit. Kurz und gut: Die Vorzüge des
WWW sind nicht mehr wegzudenken, schon gar nicht aus der Wissenschaft.
Tim Berners-Lee:
Geburt des World
Wide Web
1989 hat Tim Berners-Lee den ersten Plan für ein Informationsnetz.
Wissenschaftliche Dokumente sollen online sichtbar sein, d. h. Texte müssen
formatiert und Grafiken eingebunden werden können. Darüber hinaus möchte
Berners-Lee Hypertextfunktionalität haben, eine tatsächliche Vernetzung der
Daten. So entsteht der Name WWW World Wide Web. Die Grundsteine des
Projekts werden das Dateiformat HTML (Hypertext Markup Language) und
das neue Internet-Protokoll HTTP (HyperText Transfer Protocol). Berners-Lee
ersinnt auch das Konzept des URL [dfn-expo 2001]. Er ist zu dieser Zeit
Informatiker am CERN (Europäisches Kernforschungszentrum). Der Brite
verfeinert das WWW 1990 zusammen mit Robert Cailliau. Im November
beginnt Nicola Pellow, eine Studentin am Leicester Polytechnic in
Großbritannien, ihre Arbeit am textbasierten Browser [CERN 2001]. Neu bei
Berners-Lees System ist, dass Dokumente plattformunabhängig, d.
h.
unabhängig von verschiedenen Computersystemen und unterschiedlicher
Hardware, geöffnet werden können. Online-Betrachtung und Surfen [Ruflin
u. a. 2000] machen heute einen wesentlichen Teil des WWW aus.
Schon um Weihnachten 1990 demonstriert das CERN eine prototypische
Software. Mittels eines Interfaces für das CERN Computer Center und die
bekannten Usenet-Newsgroups erreicht man eine schnelle Akzeptanz. Alle
Informationen werden auf diese Weise sofort zugänglich, und zwar über einen
einfachen WWW-Browser [CERN 2001], [Münz 2001], [Cailliau 1995].
1991 können bereits Universitäten und Forschungseinrichtungen auf das Web
zugreifen. Kurz darauf wird der Dienst über das Internet angeboten [CERN
1997].
Realisierung einer Website auf der Basis eines UML-Entwurfes
10
Browser: Blick ins
Netz
Zunächst gibt es zwei Browserarten. Einerseits existiert die Originalversion,
die zwar sehr hoch entwickelt, aber nur für NeXT-Maschinen brauchbar ist.
Auf der anderen Seite gibt es den textbasierten Browser. Dieser ist leicht zu
installieren und läuft auf jeder Plattform. Ein solcher textbasierter Browser ist
Lynx, der im Juli 1993 in der Version 2.0 erscheint. An der Universität von
Kansas wird er von Lou Montulli, Michael Grobe, Charles Rezac und später
auch Garrett Blythe entwickelt. Lynx ist heute noch im Einsatz, er wird u. a.
von sehbehinderten und blinden Surfern und Webmastern genutzt. Denn durch
die reine Textdarstellung vereinfacht sich der Aufwand, den Inhalt einer
Webseite durch geeignete Software vorlesen zu lassen. Lynx unterstützt derzeit
den Standard HTML 4.0 [Hänel 2001].
Abb. 1.1: Lynx ein textbasierter Browser
Im Februar 1993 entwickelt Marc Andreesen am NCSA (National Center for
Supercomputing Applications) der University of Illinois eine erste Version
seines Mosaic-Browsers. Dessen grafische Oberfläche erleichtert den Umgang
mit dem Web. Ein Jahr später wird Mosaic weltweit von über 2 Millionen
Usern verwendet.
Im April 1994 geben Jim Clark (Mitgründer von Silicon Graphics) und Marc
Andreesen bekannt, dass sie eine Firma namens "Netscape Communications"
gründen wollen. Diese soll Software entwickeln, die die Nutzung des WWW
vereinfacht. Im Dezember 1994 ist der Netscape Navigator erhältlich [Jung
u. a. 1996]. 1996 erscheint der erste Opera-Browser [Opera 2001].
Im September 1995 wird von Microsoft im Zuge der Veröffentlichung von
Windows 95 eine neue Browser-Variante entwickelt, der Internet Explorer. Seit
November 1996 konkurrieren Netscape und Microsoft um die Spitzenposition
auf dem Browsermarkt [Jung u. a. 1996].
Realisierung einer Website auf der Basis eines UML-Entwurfes
11
Name
Hersteller / Autor Betriebssysteme
emacs/W3
The GNU Project
Unix, Windows u. a.
Internet Explorer
Microsoft
Windows
Konqueror
KDE e. V.
Unix
Lynx
Lynx Org.
DOS, OS/2, Unix, Windows u. a.
Mozilla
Mozilla Org.
Mac, OS/2, Solaris, Unix,
Windows u. a.
Netscape Navigator Netscape
Mac, Unix, Windows u. a.
Opera
Opera Software
Mac, OS/2, Unix, Windows u. a.
w3m
Akinori Ito
Mac, MS-DOS, OS/2, Unix,
Windows
Tabelle 1.1: Browser im Jahr 2002 (nicht vollständig)
Im September 1996 startet Cari D. Burstein die "Viewable With Any
Browser"-Kampagne, die der Entwicklung der browserabhängigen HTML- und
CSS-Umsetzung entgegenwirken will [Behme 1998]:
"Anyone who slaps a 'this page is best viewed with Browser X' label on a
Web page appears to be yearning for the bad old days, before the Web, when
you had very little chance of reading a document written on another
computer, another word processor, or another network."
(Tim Berners-Lee in Technology Review, Jul. 1996)
Es ist ärgerlich, auf einer Website herauszufinden, dass man erst eingelassen
wird, wenn man mit dem Netscape Navigator oder dem Internet Explorer
wiederkommt. Genauso unerfreulich ist es, wenn man feststellen muss, dass
browserspezifische Tags eingesetzt werden oder die Unterstützung für
textorientierte Browser fehlt.
Cari D. Burstein will diesem Trend bewusst entgegentreten. Obwohl Websites
nicht in allen Browsern gleich aussehen können, sollten sie in jedem Browser
lesbar sein [Burstein 2000].
DENIC und immer
mehr Webseiten
1991 gibt es an der Universität Dortmund den ersten freiwilligen Nameserver-
Dienst DENIC (Deutsches Network Information Center). 1993 wird der
Interessenverbund DENIC gegründet. Daraus wird 1996 die DENIC eG. 1999
benennt die ICANN (Internet Corporation for Assigned Names and Numbers),
deren Hauptaufgabe in der Verwaltung der IP-Adressen und Top-Level-
Domains liegt, Firmen, die Domain-Namen registrieren dürfen. Im Oktober
1999 übersteigt die Anzahl der registrierten Domains eine Million, im April
darauf werden zwei
Millionen registrierte Domainnamen erreicht. Im
September 2000 erhöht sich die Domainzahl auf drei Millionen, im Februar
2001 auf vier Millionen, schon im November 2001 wird die fünf-millionste
Domain vergeben [DENIC 2001]. Weltweit übersteigt die Größe des Web
eine Milliarde indizierbare Webseiten. 2001 sind es über zwei Milliarden
Seiten [dfn-expo 2001].
URL
Mit dem Konzept des Uniform Resource Locator (URL) ist es möglich,
Webseiten eindeutig zu adressieren. Das Konzept baut auf dem Prinzip des
Realisierung einer Website auf der Basis eines UML-Entwurfes
12
DNS (Domain Name System) von 1984 auf. Dieses wurde von Paul
Mockapetris an der University of Southern California in Los Angeles
entwickelt [Sillion 2001]. Der URL ermöglicht es, nicht nur auf lokale
Dokumente zu verweisen, sondern auf Dateien, die sich irgendwo im Web
befinden. Die Struktur ist wie folgt aufgebaut:
http ://
www.informatik.
oelinger
.de /math/
index.html
Protokoll
Trenn-
zeichen
Zusatz
(www oder
Subdomain)
Second-
Level-
Domain
Top-
Level-
Domain
Verzeichnis
Datei
Servername
Pfad
Abb. 1.2: Aufbau des URL
Zuerst wird das Protokoll notiert. Für das WWW ist das http. Dann folgen ein
Doppelpunkt und zwei Schrägstriche. Hinter diesem Trennzeichen schließt sich
der Servername an, bestehend evtl. aus einer Subdomain sowie der Second-
Level-Domain und der Top-Level-Domain. Im Servernamen werden die
einzelnen Bestandteile jeweils durch einen Punkt getrennt. Zum Schluss findet
sich der Pfad, bestehend aus keinem, einem oder mehreren Verzeichnissen und
der Datei selbst. Die Trennung wird jeweils durch einen Schrägstrich
angezeigt.
Ein weiteres bekanntes Protokoll ist ftp, das File-Transfer-Protocol. Dies wird
u. a. dazu eingesetzt, die Daten einer Website (html-Dokumente, Bilder und
andere Dateien) vom lokalen Rechner auf einen Server zu übertragen. https
steht für die datengeschützte Übertragung mit dem Secure-Socket-Layer-
Protokoll.
Alles, was zwischen dem Protokoll und der Second-Level-Domain steht, ist
allein Sache des Inhabers der Domain. Der URL zum Fachbereich Informatik
an der Universität Duisburg ist z. B. [Ruflin u. a. 2000]:
http://www.informatik.uni-duisburg.de/
Top-Level-
Domains
Top-Level-Domains sind entweder Country-Code-Domains oder Generic-Top-
Level-Domains, die die Website einem bestimmten Bereich zuordnen. Eine
interessante Top-Level-Domain ist .tv die Endung wird zwar gern von
Fernsehsendern genutzt, doch sie ist eigentlich eine Länderkennung, und zwar
die von Tuvalu. Die Länderkennung sagt nichts darüber aus, in welchem Land
sich der Server mit der entsprechenden Adresse befindet. Vor dem Jahr 2000
gab es lediglich sieben Generic-Top-Level-Domains. Seit 2000 gibt es noch
einmal sieben neue [Sillion 2001].
alt
für
neu
für
.com commercial Wirtschaft
.biz
business Unternehmen
.edu
education Bildung
.info
(ohne Einschränkung)
.gov government Regierungs-
behörden
.name Privatpersonen
Realisierung einer Website auf der Basis eines UML-Entwurfes
13
alt
für
neu
für
.int
organization established by an
international treaty
Organisationen, gebildet durch
einen internationalen Vertrag
.pro Anwälte,
Steuerberater,
Ärzte
.mil
military Militär
.museum Museen
.net
network Netzwerke
.aero
Luftfahrtindustrie
.org
organization Organisationen
.coop
genossenschaftliche
Organisationen
Tabelle 1.2: Generic-Top-Level-Domains Quelle: [DENIC 2001a] und [Sillion 2001]
Ausbreitung
1993 existieren weltweit 50 HTTP-Server, Ende 1994 bereits 100
000, und
1995 ist das WWW der führende Dienst des Internets [Ruflin u. a. 2000]. 1995
überholt das Web den Internetdienst FTP und wird der Service mit dem
höchsten Datenaufkommen [dfn-expo 2001].
Schließlich ist klar, dass das Team am CERN nicht mehr die gesamte
wünschenswerte Entwicklerarbeit allein erledigen kann. Tim Berners-Lee
schickt eine Bitte um Mitarbeit übers Internet [CERN 2001].
Im Oktober 1994 gründet er gemeinsam mit anderen das W3-Consortium
(W3C). Nach der ersten internationalen WWW-Konferenz am CERN in Genf
"Woodstock of the Web" [Boye 1998] wird in Boston das International
WWW Conference Committee (IW3C2) durch die CERN und das NCSA ins
Leben gerufen [Meinel, Sack 2000]. In diesem Jahr wird auch die Spezifikation
für HTML 2.0 verabschiedet [Klau 2001].
1996 werden die Spezifikationen für HTML 3.2 (HTML 2.0 plus CSS)
veröffentlicht. Der Standard wird 1997 vom W3C festgesetzt. Im Juli desselben
Jahres folgen die ersten Entwürfe für HTML 4.0 [Klau 2001], im Dezember
wird HTML 4.0 Standard [dfn-expo 2001].
2001 wird das Internet reiselustig: In Las Vegas wird ein System vorgestellt,
das eine Infrastruktur für Internetzugriffe vom Auto aus ermöglichen soll. In
Zügen und Flugzeugen gibt es Möglichkeiten, über das eigene Notebook auf
das Web zuzugreifen. Daten gibt es im Jahr 2002 genug: Wissenschaftler
schätzen die Anzahl der Websites im WWW auf neun Milliarden. Darin sind
etwa 700 TByte Informationen enthalten [Schüler 2002].
1.1.2
Schlechte und gute Beispiele für Websites
Wichtige Aspekte
Die folgenden Beispiele liefern Aspekte, die für benutzerfreundliche Websites
wichtig sind. Es werden konkrete Details erkennbar, die beim Besuch einer
Website behindern oder unterstützen. Einige der nützlichen Features aus den
Beispielen werden beim Konzept der dynamischen Website berücksichtigt.
Festgestellte Fehler werden erkannt und schon in der Entwurfsphase
vermieden.
Realisierung einer Website auf der Basis eines UML-Entwurfes
14
Schlechte Beispiele
Missverständliche
Bezeichnungen
http://reiseauskunft.bahn.de/bin/detect.exe/bin/query.exe/d
(Stand vom 22. Nov. 2001)
Das Problem bei der Fahrplanauskunft besteht darin zu erraten, was mit den
verschiedenen Aufschriften der Buttons gemeint sein mag. Zunächst muss der
Kunde seine Reisedaten eingeben. Hat man alles eingegeben, überlegt man, wo
die Suche gestartet werden kann. Leider gibt es zwei Buttons, die in Frage
kommen: "Neue Anfrage" und "Verbindungen suchen".
Der Button "Neue Anfrage" lädt die aktuelle Seite nochmal, gemeint ist also
"Verbindungen suchen". Eindeutiger wären Texte wie "Formulareingaben
löschen" (mit der entsprechenden Funktion) oder "Andere Anfrage" statt "Neue
Anfrage". Dann wäre die Bezeichnung "Verbindungen suchen" eindeutig.
Verwirrende
Übersicht
http://www.fliesen-team.de/NeueSeiten/Produktliste.html
(Stand vom 26. Nov. 2001)
In der Online-Produktliste des Fliesenteams weiß der Kunde nicht, was er mit
den unterschiedlichen Werbelogos anfangen soll. Besser wäre es, die
Produktliste wirklich als Liste zu realisieren und zu jedem Eintrag einen kurzen
Kommentar zum jeweiligen Produkt zu schreiben. Optimal wäre es, dazu noch
Informationen wie Zubehör (z. B. Fliesenkleber), Preise und Lieferzeiten
anzugeben. Der Kontrast zwischen Hintergrund und Text ist zu gering. Das
Hintergrundbild wird gekachelt, so dass ein Versatz auf der rechten Seite
entsteht. Es ist darüberhinaus sehr unruhig und lenkt von den Elementen im
Vordergrund ab. So kann man den eigentlichen Inhalt nur schwer erfassen und
die Texte schlecht lesen.
Abb. 1.3: Fehlendes Bild und unbeabsichtigte Hintergrundkachelung (s. rote Markierung)
Deutlich zu sehen ist hier auch ein Fehler des Webmasters: Es fehlt ein Bild.
Das wirkt einen ungepflegt und beeinträchtigt den ersten Eindruck.
Realisierung einer Website auf der Basis eines UML-Entwurfes
15
Navigation, Design
und Styles
http://www.heinemann-und-partner.de
(Stand vom 22. Nov. 2001)
An diesem Beispiel ist leicht zu sehen, warum Testen in verschiedenen
Browsern so wichtig ist. Außerdem sollte man vermeiden, für verschiedene
Funktionen gleiche Schriftformatierung zu benutzen. Sonst ist der Besucher der
Website verwirrt.
Navigation ins
Leere?
Die Site hat den Nachteil, dass es nicht für jeden Surfer über die Navigation zu
den Unterseiten geht. Die Startseite ist für den Internet Explorer, der keine
Scripts (d h. Elemente einer Skriptsprache) erlaubt, die einzige Seite, die zu
erreichen ist. Klickt man die Menüpunkte an, tut sich nichts. Das liegt daran,
dass die Navigation über Scripts realisiert ist. Einzige Ausnahme: Der Email-
Link funktioniert. Dieser Fehler dürfte nicht wenige Surfer frustriert davon
abhalten, Kontakt aufzunehmen und zu Kunden zu werden.
Design nur für
unseren Browser
Opera und Netscape lassen den Besucher weiterkommen. Im Internet Explorer
sieht die Startseite so aus:
Abb. 1.4: Schlichte Startseite
An sich ist am Design nichts auszusetzen. Es ist schlicht und übersichtlich. Es
wird klar, was die Seite anbietet, wer der Urheber ist, wo sich die Navigation
befindet und nach kurzem Überlegen findet man auch die Möglichkeit, per
Email Kontakt aufzunehmen. Eine andere Ansicht jedoch bekommen Surfer,
die andere Browser benutzen. Opera zeigt das Design so an:
Realisierung einer Website auf der Basis eines UML-Entwurfes
16
Abhängigkeit vom
Browser
Abb 1.5: Fehlerhafte Darstellung in Opera
Hier liegt der Schriftzug über dem Text, so dass sich dieser nicht mehr lesen
lässt. Außerdem ist die linke Randleiste verschoben. Es wird deutlich, dass das
Design bzw. der Entwurf anhand der fertigen HTML-Seiten in den gängigen
Browsern getestet werden sollte. Idealerweise sieht man sich die Anzeige auch
auf verschiedenen PC-Betriebssystemen an.
Inkonsistenz bei
den Styles
Auf verschiedenen Unterseiten entdeckt man dann dieselben hervorgehobenen
Texte. Einmal ist es kein Link:
Abb 1.6: Farbige Texte sind keine Links
Auf einer anderen Seite ist es doch ein Link. Die Doppeldeutigkeit der
Schriftformatierung geht zu Lasten des Besuchers. Er wird entweder Zeit
verlieren oder eine Funktion nicht erkennen. Zeit verliert er, falls er eine
Funktion vermutet, die nicht vorhanden ist (Abb. 1.6).
Realisierung einer Website auf der Basis eines UML-Entwurfes
17
Abb 1.7: Farbige Texte sind Links
Eine Funktion, die woanders nicht vorhanden ist, sucht er hier nicht und
kommt gar nicht erst zu den Inhalten, die für ihn bestimmt sind (Abb 1.7).
Gute Beispiele
Redundanz als
Hilfsmittel
www.rp-online.de/news/lokales/
(Stand vom 08. Jan. 2002)
Die Online-Ausgabe der Rheinischen Post, einer Tageszeitung, ist gut
strukturiert. Auf der Seite der Regionalteilauswahl kann der Besucher auf
dreierlei Weise seinen Lokalteil auswählen:
Über eine Imagemap, die die Karte mit den Städten darstellt oder
Über eine vollständige Liste, aufgeteilt nach Printprodukten des Angebots
oder
Über ein Pull-Down-Menü
Abb. 1.8: Redundanz für verschiedene Wahrnehmungstypen
Was nach überflüssiger Wiederholung aussieht, ist gut durchdacht. Die
Realisierung einer Website auf der Basis eines UML-Entwurfes
18
Redundanz des Inhalts ermöglicht es, verschiedenen Surfgewohnheiten
entgegen zu kommen. So kann der Besucher je nach Wahrnehmungstyp sehr
schnell an sein Ziel gelangen. Denn Menschen nehmen ihre Umgebung
unterschiedlich wahr. Es gibt visuelle Wahrnehmungstypen, die verstärkt durch
Grafiken angesprochen werden. Andere bevorzugen Übersichten, wieder
andere suchen lieber schnell und gezielt aus. Das Layout der
Regionalteilauswahl bietet jedem dieser Typen die Möglichkeit, sofort und
ohne nachzudenken dorthin zu gelangen, wohin er möchte.
Animierte GIFs
http://home.t-online.de/home/Lienke/bifaz.htm
(Stand vom 22. Nov. 2001)
Ein anschauliches Verkehrszeichen ist das "Achtung Steinschlag"-Schild. Der
Urheber der Seite weist darauf hin, dass gerade dieses Schild natürlich
noch besser wahrzunehmen ist, wenn es animiert wird. Deshalb wird
auf den bifaz-Seiten die Technik des animierten Verkehrszeichens
für Steinschlag erklärt. Um einen Eindruck zu bekommen, habe ich
wichtige Phasen der "Technik" abgebildet:
Abb. 1.9: Animiertes Steinschlag-Schild
Hier bleibt kein Zweifel, wie es funktioniert. Dies ist eine Anwendung, in der
der Einsatz von animierten GIFs wirklich nicht nur angebracht, sondern sogar
unumgänglich ist. Für den Entwurf von Websites lässt sich der Schluss ziehen,
dass man Möglichkeiten dann nutzen sollte, wenn sie sinnvoll sind. Man sollte
aber der Versuchung widerstehen, jede Funktionalität in jede Website zu
zwängen.
Selbsterklärendes
Layout
www.vz-nrw.de
(Stand vom 08. Jan. 2002)
Die Verbraucherzentrale hat eine sehr übersichtliche Site. Es ist ersichtlich,
bei wem man gelandet ist (Logo oben links),
welche Navigation wofür steht (rot für Themen, blau für Service),
wo die Hilfsnavigation ist (oben: Suche, Impressum, Über uns und
Kontakt).
Realisierung einer Website auf der Basis eines UML-Entwurfes
19
Screenshot
Homepage
Abb. 1.10: Feature Druckversion (s. rote Markierung oben rechts)
Druckversion
Von jeder Seite gibt es eine Druckversion. Darin erscheinen dann nur die
Informationen, die für die Papierversion wichtig sind: Die Navigation entfällt
und der URL wird innerhalb der Seite angegeben.
Druckversion der
Homepage
Abb. 1.11: URL-Angabe: So findet man die Seite leicht wieder
Leider ist hier im URL ein kleiner Tippfehler enthalten (statt des korrekten
.de
steht dort
de
), und die Schriftart sollte für eine Druckversion Serifen haben,
weil diese die Lesbarkeit auf Papier erleichtern. Ansonsten ist diese Seite aber
vorbildlich.
Realisierung einer Website auf der Basis eines UML-Entwurfes
20
Sie enthält im Fuß noch die restlichen notwendigen Angaben:
Aktualität
Abb. 1.12: Der Besucher kann selbst entscheiden, ob die Information für ihn aktuell ist
Das Datum sollte man niemals vergessen, denn viele Informationen veralten
schnell. Außerdem ist es eine gute Idee, die Adresse der Verbraucherzentralen
mit anzugeben.
Realisierung einer Website auf der Basis eines UML-Entwurfes
21
1.2 Vorgehensweise
Zielsetzung
Ziel der Arbeit ist es, eine Materialsammlung in einer dynamischen Website
optimal zugänglich zu machen. Dabei soll die Sammlung neue Materialien
aufnehmen können, verschiedene Dateiformate anbieten und die Suche nach
Inhalten erleichtern.
Nachdem der Entwurf der Website durch den Gesamtkontext im WWW und
einige Möglichkeiten anhand von Beispielen motiviert ist, wird nun die
Vorgehensweise dargestellt.
Begriffsklärung
Der Begriff der Webmistress wird in dieser Arbeit statt des gebräuchlichen
Webmasters benutzt. Der Begriff der Website umfasst alle HTML-Seiten und
die anderen Elemente, d. h. Bilder, Dokumente und natürlich auch die Style-
Sheet-Dateien. Der Begriff Feature umfasst mögliche Funktionalitäten und
Serviceangebote einer Website. Ein Feature kann aus mehreren Dateien oder
bestimmten Codeabschnitten bestehen. Es wird als Modul betrachtet, das als
einzelne Komponente einer Website hinzugefügt werden kann.
Analyse, Konzept
und Realisierung
Zunächst werden die Anforderungen für die Realisierung dieser Website
festgestellt. Die Analyse der zur Verfügung stehenden Inhalte bildet die
Grundlage für die theoretische Konzepterstellung. Dazu werden die
Möglichkeiten der allgemeinen Funktionalität sowie die Machbarkeitskriterien
in Kapitel 3.4 aufgelistet und anschließend ausgewählt. Die theoretische
Grundlage UML wird erklärt. Darauf aufbauend erfolgt die Bewertung und
Auswahl der UML-Diagramme als Voraussetzung für die Umsetzung. Zur
Beschreibung der potentiellen Zielgruppe werden Szenarien aufgestellt, die
Inhaltssuche durch Strukturierung vorbereitet und die Basissoftware
besprochen. Die Dateiformate und ihre Aufgaben werden vorgestellt. Nach
dem Layoutentwurf folgt die Realisierung und Dokumentation inklusive
notwendiger HTML-Dateien und Strukturübersichten. Dem Web Application
Server Dado wird ein eigener Abschnitt gewidmet. Schließlich endet die Arbeit
mit einer Bewertung und einem Blick auf zukünftige Möglichkeiten.
Stil
Im Text werden deutsche Begriffe bevorzugt. Nur bei Fachbegriffen und
Bezeichnungen für Diagramme, Ordner, Tabellen, HTML-Seiten etc. wird auf
das Englische zurückgegriffen. Da die englischen Begriffe meist kürzer oder
eindeutiger sind, sind Grafiken und Diagramme mit englischen Bezeichnungen
übersichtlicher.
Anhang
Im Quellenverzeichnis finden sich neben der Literaturliste auch die
Internetquellen und eine Software-Übersicht. Danach folgt eine Übersicht über
die bisher veröffentlichten Materialien. Um die Umsetzung mittels des Dado
Application Servers, einem Web Application Server, zu erläutern, werden im
Anhang die verwendeten Befehle aufgeführt. Zum Kapitel 5 gehört der
Datenbankentwurf anhand eines Diagrammes und einer Auflistung der DB-
Tabellen. Anschließend werden im Glossar die wesentlichen Fachbegriffe kurz
erklärt. Ausführliche Erläuterungen findet man in den jeweiligen Kapiteln.
Realisierung einer Website auf der Basis eines UML-Entwurfes
22
1.3 Problembeschreibung
Zielgruppe
Eine wichtige Frage ist die nach den Bedürfnissen der Zielgruppe: Wer ist an
den Daten überhaupt interessiert und wie kann dem potentiellen Besucher der
Site der gewünschte Inhalt am komfortabelsten zugänglich gemacht werden?
Sollen nur Profis oder auch Einsteiger angesprochen werden? Wie muss das in
Konzept und Design berücksichtigt werden? Was möchte der Besucher?
Welche Funktionalitäten und Serviceangebote passen zu den Vorkenntnissen
und Ansprüchen der Besucher?
Die Zielgruppe besteht aus allen, die sich für die Bereiche Informatik und
Mathematik sowie für (interaktive oder multimediale) Kunst interessieren. Das
Design muss also auf fachlich Interessierte zugeschnitten werden, d. h. das
Layout soll sehr schlicht sein, damit es die Inhalte in den Vordergrund rückt
und nicht vom Wesentlichen ablenkt. Sowohl Wissenschaftler als auch
Einsteiger sollen angesprochen werden. Darauf zugeschnitten wird die
Auswahl der Features, die angeboten werden.
Strukturierung und
Technik
Die Materialsammlung der Lehrmaterialien soll im Web zugänglich gemacht
werden. Das Problem besteht einerseits in der logischen Strukturierung der
vorhandenen Daten. Andererseits soll dem Besucher der Site ein hohes Maß an
Usability geboten werden. Es soll intuitiv möglich sein, alle vorhandenen
Informationen schnell zu finden. Die vorhandenen Funktionalitäten sollen
selbstverständlich und ohne Nachdenken genutzt werden können.
Die Projektstruktur besteht aus der Ordnerstruktur, der Datenbankstruktur
sowie dem Konzept. Grundlage dafür sind zunächst die Materialien, also die
Skripte, Vortragsunterlagen, Prüfungsprotokolle und andere Dokumente, die
bisher schon veröffentlicht sind. Auf der einen Seite geben die Bedürfnisse und
Wünsche der Benutzer den Rahmen für die Umsetzung vor. Dem gegenüber
stehen die programmiertechnischen Einschränkungen; nicht alles, was
wünschenswert ist, lässt sich angemessen umsetzen.
Die alte Ordnerstruktur kann nicht übernommen werden, da die Fachgebiete
bisher jeweils einen eigenen Ordner bekommen haben. Die Materialien werden
für die neue Site in einer Datenbank gespeichert, so dass sämtliche Skripte in
derselben Tabelle landen, mit Relationen zum entsprechenden Fachgebiet. Es
muss eine neue, sinnvolle Ordnerstruktur mit leicht verständlichen Namen her.
Die Datenbankstruktur muss auf der Basis des Klassendiagramms für die
Materialien in Kapitel 3.1 entwickelt werden. Dabei werden die nicht-
inhaltsbezogenen Features wie etwa der Papierkorb und die Zugriffsverwaltung
berücksichtigt. Das Ganze muss im Konzept in Kapitel 4 verarbeitet und
weitergeführt werden. Schließlich erfordert die Umsetzung in Kapitel 5 eine
Projektstruktur, die sich auch tatsächlich realisieren lässt.
Die Vorgabe, alle Dateien mit aussagekräftigen Namen zu versehen, stößt
durch die automatische Benennung durch die Datenbank an ihre Grenzen.
Dieses Problem lässt sich größtenteils durch die Angabe eines Namens bzw.
eines Altenativtextes für Bilder lösen. Das gilt allerdings nur für den Fall, dass
Bilder direkt in die HTML-Seiten eingefügt werden. Bilder, die beim Datentyp
wysiwyg
in den Text übernommen werden, erhalten den generierten Namen.
Dieser Datentyp erlaubt auch nicht das Einfügen eines alternativen Textes.
Realisierung einer Website auf der Basis eines UML-Entwurfes
23
Materialien
Die Materialsammlung besteht aus verschiedenen Grafik- und Textformaten.
Dazu kommt das Problem der Formeln, die als Grafiken in den HTML- und
Word-Dokumenten enthalten sind. MathML kommt hierbei nicht in Frage, da
dies bisher noch zu wenige Browser unterstützen. Die Website wird in der
Ausgabe komplett zweisprachig sein. Einige der Materialien liegen sowohl auf
Englisch als auch auf Deutsch vor. Neben einer vollständigen Vokabelliste ist
eine Vokabelsuche wünschenswert. Um eine übersichtliche Ausgabe von
Suchergebnissen zu ermöglichen, werden für das geplante Fachwörterbuch
zwei Tabellen angelegt. Die eine für die deutsch-englische Ausgabe, die andere
für die englisch-deutsche.
So kann bei Mehrfachbedeutungen die Ausgabe wie
bei einem herkömmlichen Lexikon aussehen:
"subset Teilmenge, Untermenge"
statt
"subset Teilmenge
subset Untermenge"
Service
Es ist eine Serviceseite vorgesehen, auf der die folgenden Dienste angeboten
werden:
Table of Contents, d. h. ein Inhaltsverzeichnis
Sitemap, eine grafische Übersicht über die Inhalte
Gesamtglossar
Titelverzeichnisse (alle Skripte, Prüfungsprotokolle, Downloads etc.)
Login (Admininterface und geschützte Bereiche für Besucher)
Suchergebnisse
Suchergebnisse sammeln
Linkliste
Kontakt
Eine eigens vorgesehene Datenbanktabelle macht Stichwörter für verschiedene
Einträge zugänglich und wird für die Suchmaschinenoptimierung eingesetzt.
Beim Loginbereich stellt sich die Frage, wer was darf und wie die Inhalte
gegen unbefugten Zugriff geschützt werden können. Mehr zum Service für
Besucher der Website findet sich in den Use-Cases und in der
Machbarkeitsübersicht in Kapitel 3 sowie in den Szenarien in Kapitel 4.
Eine weitere Aufgabe stellt sich bei der Einteilung des geschützten Bereiches.
Denkbar sind folgende Nutzergruppen:
Die Gruppe
contenteditor
und
contentmanager
zur Verwaltung
der Inhalte
Die Gruppe
webmistress
für die Administration
Die Gruppe
guest
für Besucher, die Zugang zu Inhalten erhalten, die nur für
angemeldete Besucher gedacht sind (Fotos, Dateien, Texte).
Bereits jetzt liegen manche Skripte nicht nur auf Deutsch, sondern auch auf
Englisch vor. Diesem Umstand soll Rechnung getragen werden, indem die
gesamte Website zweisprachig angeboten wird. Das heißt, dass in der
Datenbank für alle Materialien Textfelder für beide Sprachen vorhanden sein
müssen. Es müssen auch Bilder, die ja Text enthalten können, in zwei Sprachen
speicherbar sein. Auch Texte, die nicht aus der Datenbank kommen, müssen
zweisprachig angelegt werden. Eine Umschaltfunktion zwischen den beiden
Sprachen wird durch Buttons realisiert.
Realisierung einer Website auf der Basis eines UML-Entwurfes
24
Alle Inhaltsseiten erhalten ein Datum, an dem der neueste zugehörige Eintrag
gespeichert wurde. Das Problem bei Übersichtsseiten mit Inhalten aus
verschiedenen DB-Tabellen ist, dass es nicht immer alles gibt. So kann es
Übersichten geben, in denen keine Prüfungsprotokolle vorkommen oder keine
Quellen. Da es Skripte immer gibt, wird das Datum des zuletzt eingegebenen
Skriptes eingesetzt, das dem Bereich bzw. Fachgebiet zugeordnet ist.
Design
Das Design soll übersichtlich sein und trotzdem alle wichtigen Informationen
bereitstellen. Die gesamte Website www.informatik.oelinger.de soll einheitlich
sein, so dass Besucher in jeder Unterseite wissen, dass sie sich noch in der
selben Site aufhalten. Ein Farbschema erleichtert die Orientierung: Es ist
möglich, für unterschiedliche Sektionen verschiedenen Farben zu verwenden,
die durch das Design ihre Zusammengehörigkeit erhalten. Falls später jedoch
mehr als die anfänglichen drei Bereiche Mathematik, Informatik und Kunst
angeboten werden, ergibt sich ein Problem: Es wird dann schwierig, genügend
Farbschemata zu finden, die sich voneinander unterscheiden, miteinander
harmonieren und außerdem noch eine gute Lesbarkeit aufweisen. Deshalb wird
die gesamte Website ein einheitliches Farbschema erhalten.
Browser-
unabhängigkeit
Eine der größten Herausforderungen beim Webdesign ist die
browserunabhängige Gestaltung. Anweisungen werden sehr unterschiedlich
interpretiert. So ist es unumgänglich, die Website von Anfang an und bei jeder
Designänderung in verschiedenen Browsern zu testen. Besonders bei
Tabellenattribute wie Breiten- und Höhenangaben oder beim Ausrichten von
Bildern und Text werden stark voneinander abweichende Ergebnisse angezeigt.
Realisierung einer Website auf der Basis eines UML-Entwurfes
25
2. ANFORDERUNGEN
2.1 Anforderungen und Skalierbarkeit
Vorbereitung
Bevor die gewünschten Funktionen und das Konzept festgelegt werden
können, muss analysiert werden, welche Anforderungen die Website später
erfüllen soll. Neben der Benutzerfreundlichkeit stehen die Skalierbarkeit und
die Erweiterbarkeit im Vordergrund. Mit anderen Worten, die Pflege und der
Ausbau der Website sollen mit möglichst wenig Aufwand verbunden sein.
Skalierbarkeit vs.
Erweiterbarkeit
Skalierbarkeit bedeutet, dass der gesamten Struktur neue Features hinzugefügt
werden können. Es sollen problemlos neue Datenbanktabellen für neuartige
Inhalte angelegt und ganze Bereiche zur Website hinzugefügt werden können,
ohne den Gesamteindruck oder gar die vorhandene Struktur der bestehenden
Website zu ändern. Dies soll mit minimalem Aufwand möglich sein.
Erweiterbarkeit dagegen bedeutet, dass beliebig viele Inhalte in der Datenbank
angelegt werden können. Neue Fachgebiete, Skripte, Quellen etc. werden
einfach in der Datenbank gespeichert und durch die vorgegebene Struktur wie
die anfangs vorhandenen Inhalte angezeigt.
Quelltextschnippsel Für sich wiederholende Anforderungen in den HTML-Seiten werden im Code
Quelltextschnippsel eingesetzt, die in ähnlichen Seiten nur noch angepasst
werden müssen. Dazu gehört z. B. die Sprachabfrage:
<! if cond="'$(global.language)'=='1'" :>
[-- out field="name" --]
<! else >
[-- out field="name_en" --]
<! end >
Die Variable
$(global.language)
speichert siteweit die aktuell gewählte
Sprache. Falls der Wert der Variablen
1
ist, bedeutet das, dass die aktuell
eingestellte Sprache Deutsch ist. Ist das der Fall, wird der deutsche Text
name
aus der Datenbank ausgelesen und angezeigt. Andernfalls erscheint der
englische Text
name_en
.
2.1.1 Templates
Was sind
Templates?
Templates sind Dateien, die das formale Gerüst enthalten, das mehrere HTML-
Seiten verbindet. HTML-Editoren wie Dreamweaver [Dreamweaver 2002]
können Templates anlegen, die bei Bedarf jede Änderung auf alle damit
verbundenen HTML-Seiten übertragen. Neue HTML-Seiten können direkt mit
den Vorgaben des Templates erstellt werden. Selbst ohne eine solch
komfortable Unterstützung durch den HTML-Editor lassen sich Templateseiten
anlegen: Das sind im einfachsten Fall Textdateien, die
<head>
- und
<body>
-
Angaben und die entsprechenden Tabellen, CSS-Angaben etc. enthalten. Sie
sind schon so weit gestaltet, dass das grobe Layout als Grundgerüst vorhanden
ist. Möchte man neue HTML-Seiten im gleichen Stil anlegen, speichert man
einfach die Textdatei als neue HTML-Datei ab.
Realisierung einer Website auf der Basis eines UML-Entwurfes
26
Wozu Templates?
Es spart Zeit und Arbeit, wenn man auf Vorhandenes zurückgreifen kann.
Besonders effizient ist die Template-Funktion einiger HTML-Editoren, die
Änderungen auf Knopfdruck automatisch zu aktualisieren. Bei Änderungen des
Layouts, der Beseitigung von Fehlern im Design oder bei Textänderungen
sowie dem Austausch von Bildern ist es eine immense Aufwandsersparnis,
wenn man ein Template benutzt, mit dem man die Änderungen gleich auf alle
damit verbundenen HTML-Seiten überträgt.
Vorteile
Der Einsatz von Templates vereinfacht die spätere Pflege und Erweiterung der
Site. Bei Erweiterungen, z.
B. neuen Features, kann das Template als
Grundlage dienen. Bei Änderungen genügt es, die Templateseite anzupassen
und alle angeschlossenen Seiten zu aktualisieren. Die Wiederverwendbarkeit
und die Vorteile bei Änderungen und Erweiterungen sprechen ganz klar für den
Einsatz von Templates.
Nachteile
Ändert man im gemeinsamen Quellcode etwas in einer einzelnen HTML-Seite,
die mit einem Template verbunden ist, so wird diese Änderung beim
Aktualisieren durch das Template natürlich wieder überschrieben. Das
bedeutet, dass der Entwickler darauf achten muss, wo gemeinsame Abschnitte
vorkommen und wo es vielleicht sinnvoll ist, verschiedene oder auch keine
Templates zu benutzen. In der Praxis kann es durchaus vorkommen, dass ein
Stromausfall während des automatischen Aktualisierens sämtliche HTML-
Seiten zerstört.
2.1.2 Flexibel
erweiterbare
Struktur
DB-Struktur
Die DB-Struktur soll beliebig viele neue Bereiche, neue Fachgebiete etc.
erlauben. So ist gewährleistet, dass nicht nur neue Skripte problemlos eingefügt
bzw. alte gelöscht werden können, sondern ganze Zweige in der Menüstruktur
angelegt oder entfernt werden können. Lediglich die Imagemap für die
Hauptnavigation muss dann natürlich erneuert werden.
Ordnerstruktur
Auch die Ordnerstruktur muss von vornherein so angelegt sein, dass
Erweiterungen problemlos möglich sind. Denn hier sind Änderungen mit
hohem Aufwand verbunden, da die internen Links, Pfade zu Bildern,
Downloads etc. angepasst werden müssen. Außerdem erleichtert es die Arbeit,
wenn die Ordner sinnvolle Namen bekommen. Die Struktur sollte in allen
Ordnern beibehalten werden. Es ist also sinnvoll, z. B. in jedem Ordner, in dem
HTML-Seiten mit Bildern abgespeichert sind, einen Unterordner für Bilder
anzulegen und diese Unterordner dann in allen Ordnern gleich zu benennen.
Dateibenennung
Die Namen der einzelnen Dateien sollten so weit wie möglich selbsterklärend
sein. Ansonsten wäre es notwendig, bei der Realisierung ständig nachzusehen,
was denn nun in welcher Datei steht. Auch für die Besucher der Site ist es
angenehmer, "sprechende Namen" für Grafiken vorzufinden. Das ist etwa für
Suchmaschinen sinnvoll. Hat ein Surfer das Bild über eine solche
Suchmaschine gefunden, kommt er vielleicht auch wegen der restlichen Inhalte
als Besucher auf die Site. Ein Name wie
img_01.gif
erschwert die Arbeit,
ein Name wie
search.gif
erleichtert sie. Das lässt sich leider nur für die
Bilder im Design realisieren. Denn die Bilder, die in der Datenbank gespeichert
werden, erhalten automatisch generierte Namen. Um so wichtiger ist es, dafür
einen aussagekräftigen Alternativtext anzugeben. Damit kann man dem Bild
wieder seinen Inhalt als Textbeschreibung mit auf den Weg geben.
Realisierung einer Website auf der Basis eines UML-Entwurfes
27
2.1.3 Erstellung
und
Pflege
Aufbau
Zunächst müssen die Inhalte geordnet werden. Sie werden in Bereiche und
diese dann in Fachgebiete aufgeteilt. Die einzelnen Dokumente werden
innerhalb der Fachgebiete nach ihrem Typ (Prüfungsprotokoll, Download,
Glossareintrag o. ä.) sortiert. Nach dieser Vorarbeit wird die Datenbank
aufgebaut, danach werden Templates für Ausgabe und Admininterface sowie
Untersites mit besonderen Funktionalitäten (wie das Fachwörterbuch) angelegt.
Dazu kommt die Dokumentation, um die Pflege zu erleichtern und
Erweiterungen sinnvoll einbringen zu können. Der Styleguide sollte sämtliche
Daten zum Design und Style enthalten.
Eingeben, Ändern
und Löschen: Das
Admininterface
Das Administrationsinterface (kurz: Admininterface) muss ermöglichen, neue
Einträge vorzunehmen, vorhandene zu ändern und alte zu löschen. Dazu
benötigt man einerseits Seiten, auf denen man Neues in die Datenbank
schreiben kann. Zusätzlich muss es Seiten geben, die die Möglichkeit bieten,
vorhandene Inhalte zu ändern. Dort kann auch die Löschfunktion untergebracht
werden. Das Admininterface wird durch eine Passwortabfrage geschützt. So
können nur befugte Personen die Daten verwalten.
Durch verschiedene Zugriffsrechte können Gruppen und beliebig viele User zu
diesen Gruppen angelegt werden. So lässt sich z. B. gewährleisten, dass nicht
jeder, der ändern darf, auch löschen kann. Wie ist das zu verstehen?
Angenommen, der Redakteur darf ändern und der Chefredakteur darf löschen.
Natürlich kann der Redakteur beim Ändern die Einträge der Felder, die ihm
zugänglich sind, aus der entsprechenden Datenbanktabelle durch "nichts"
ersetzen. Aber er kann den Eintrag selbst nicht aus der Datenbank löschen. Das
kann nur der Chefredakteur, der beim Löschen die Zeile aus der
Datenbanktabelle entfernt, die durch die ID eindeutig gekennzeichnet ist.
Um unbeabsichtigtes Löschen zu vermeiden, können Inhalte in der Datenbank
mit dem Status "Papierkorb" versehen werden. So kann man durch
Rechtevergabe das Verschieben in den Papierkorb und das endgültige Löschen
voneinander trennen und auf verschiedene Personen verteilen.
Dokumentation
In der Dokumentation stehen alle wichtigen technischen und logischen Daten
der gesamten Site. Auch die Übersicht über die Zugriffsrechte
gehört hierher.
Welche Pfade innerhalb der Ordnerstruktur müssen bekannt sein, welche
Datenbanktabellen gibt es, wie sind sie miteinander verknüpft?
Styleguide
Der Styleguide enthält Angaben zum Layout der Website. Dazu gehören
Bilder, Farben und Angaben zu CSS: Welche Styles gibt es? Was genau in
einem Style steht, gehört nicht hierher. Das steht in der
css
-Datei. Allerdings
sollte vermerkt sein, welche Formatierungen es gibt, z.
B.
.text
,
.breadcrumb
o. ä. und ihre Funktion, also Stile für den Text und für den
Wegweiser. Eine Übersicht über die Farben der Site und ihre verschiedenen
Funktionen ist hilfreich: Welche Farben für den Hintergrund und welche
Farben für Tabellen? Welche Farben werden grundsätzlich für Schrift, also
Texte, Links usw. verwendet? Welche Bilder gibt es in der Website und welche
Aufgabe haben sie? Schließlich kann eine grobe Designskizze und
Designbeschreibung hilfreich sein. Mit dem Styleguide sollte jeder problemlos
neue Seiten im Stil der alten erstellen können.
Final del extracto de 134 páginas
- Citar trabajo
- Maria Oelinger (Autor), 2002, Realisierung einer Website auf der Basis eines UML-Entwurfes am Beispiel einer Materialsammlung aus Informatik und Mathematik, Múnich, GRIN Verlag, https://www.grin.com/document/185775
Textos similares
Así es como funciona
✕
Extracto de
134
Páginas
Comentarios