Entwurf und Realisierung einer Internetplattform für den Verlag von ...

TU Wien
Business Informatics Group
Institut für Softwaretechnik und Interaktive Systeme
________________________________________________________________________________
Entwurf und Realisierung einer Internetplattform
für den Verlag von fotounterstützten
Dokumentationen alpiner Touren
Diplomarbeit zur Erlangung des akademischen Grades eines
Diplom Ingenieurs
eingereicht bei o. Univ.­Prof. Mag. Dipl.­Ing. Dr. Gerti Kappel
Dipl.­Ing. Walter Sunk
Wien, 30.08.2006

Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe
verfasst, andere als die angegebenen Quellen nicht benutzt und die den benutzten Quellen wörtlich
oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe.
Wien, 30.08.2006 Walter Sunk
ii

Kurzfassung
Immer mehr Wanderer und Bergsteiger werden durch die Faszination der Gebirgswelt sowie deren
Erlebnis­ und Erholungswert in das Gebirge gezogen. Voraussetzung zum erfolgreichen und
sicheren Durchführen von Touren im Gebirge ist eine sehr genaue Tourenplanung. Diese erhöht die
Sicherheit und somit den Erlebniswert.
Von besonderem Interesse bei der Tourenplanung sind genaue Informationen über den
Tourenverlauf sowie über mögliche Gefahren­ und Schlüsselstellen. Die meisten Informationen
werden in Textform angeboten. Sowohl Fachliteratur als auch Informationen im Internet
beschreiben Touren überwiegend in Worten, es fehlt in der Regel gutes Fotomaterial. Doch gerade
dieses verbessert die Vorstellung über eine alpine Tour ganz wesentlich. Sowohl die Orientierung
vor Ort als auch die Einschätzung von Schlüsselstellen in der Tour werden durch vorher bekanntes
Fotomaterial wesentlich erleichtert.
Aus diesem Grund beschäftigt sich die vorliegende Arbeit mit der Entwicklung einer
Internetplattform für den Verlag von fotounterstützten Dokumentationen alpiner Touren. Jede
Dokumentation soll dabei genügend Fotomaterial enthalten können, um den gesamten Verlauf einer
Tour sowie alle Schlüsselstellen auf der Tour sichtbar zu machen. Die Internetplattform unterstützt
also Wanderer und Bergsteiger dabei, ausreichend Bildinformation über bevorstehende Touren für
eine ausführliche Tourenplanung zu erhalten. Umgekehrt haben Tourengeher auch die Möglichkeit,
als Alpinautoren fotounterstützte Dokumentationen alpiner Touren zu publizieren.
Da das Durchführen und Erstellen derartiger Dokumentationen stets mit viel Zeit und Kosten
verbunden ist, sollen die Kosten durch Verkauf der Dokumentationen nach Möglichkeit gedeckt
werden. Die Internetplattform stellt dafür ein geeignetes Verkaufssystem zur Verfügung.
Die Plattform wurde mit Sommerbeginn 2006 eröffnet 1) und stellt als Basisinhalt einen Osttirol
Wander­ und Hochtourenführer sowie einen kleinen Zentralpyrenäen Wanderführer zur Verfügung.
Da es Berge weltweit gibt und Alpinisten unterschiedlichste Sprachen sprechen, wurde die
Internetplattform mehrsprachig ausgeführt, zur Zeit in den Sprachen Deutsch, Englisch und
Französisch. So haben Autoren die Möglichkeit, Dokumentationen in mehreren Sprachen zu
publizieren und Tourengeher können Dokumentationen in mehreren Sprachen beziehen.
Die vorliegende Arbeit beschäftigt sich mit der Entwicklung dieser Plattform. Zuerst wird eine
Anforderungsanalyse erstellt, welche die Anforderungen einer solchen Plattform aufzeigt. Basierend
auf diesen Anforderungen wird die Plattform anschließend modelliert. Der Schwerpunkt der
vorliegenden Arbeit liegt in der Modellierung. In dieser werden sämtliche Modelle aufgezeigt, die
für eine Realisierung einer derartigen Plattform notwendig sind. Aufbauend auf der Modellierung
werden die wichtigsten Teile einer möglichen Implementierung genauer besprochen. Auch
rechtliche Grundlagen zum Betrieb der Plattform werden abschließend erörtert.
Gezeigt wird, dass für die Umsetzung eines derartigen Verlages neben umfangreichen technischen
und sprachlichen Kenntnissen sowie neben Erfahrungen in der Alpinistik auch grundlegende
Kenntnisse in den Gebieten der Buchhaltung und im Daten­ und Informatikrecht notwendig sind.
Die Realisierung der Plattform stellt sich diesbezüglich als ein multidisziplinäres Projekt in dem
spannenden Gebiet des Bergsports heraus.
1) http://www.AlpinImageS.com/ iii

Abstract
More and more hikers and mountaineers go on alpine tours because of the great fascination, the
adventure and the possible relaxation that can be enjoyed in the mountains. A precondition for a
successful and safe tour in the alpine area is a detailed tour planning. A well­done tour planning
increases safety during a tour and makes the tour more enjoyable.
While planning a tour information about the route as well as about possible dangerous and difficult
spots is of great interest. Most of the information that can be found about alpine tours is in a textual
form. Specific literature as well as information in the internet are mostly text based, normally good
photos are missing. However, informative photos can help to improve one's imagination of a tour to
a great extent. Photos can be very helpful to make the orientation during a tour as well as the rating
of difficult spots much easier.
For this reason this thesis deals with the development of a website for publishing photo­assisted
documentations of alpine tours. Thereby each documentation should provide enough photos in order
to get a good overview of the whole route and to provide an insight into difficult spots. Thus the
website assists hikers and mountaineers to get enough photos of upcoming tours in order to perform
a detailed tour planning. On the other hand hikers and mountaineers have the possibility to publish
photo­assisted documentations of alpine tours as alpine authors.
Due to the fact that performing and documenting alpine tours in such an extent costs usually much
money and time, the costs should be covered by selling the documentations. Therefore the website
provides an appropriate selling system.
The website was opened with the beginning of summer 2006 1) and provides a guide for tours in the
mountains of Eastern Tyrol and a small guide for tours in the Central Pyrenees.
Mountains exist all over the world and hence mountaineers speak many different languages. For this
reason the website was developed multilingual and supports the languages English, French and
German. Thereby authors have the possibility to publish documentations in several languages and
mountaineers have the possibility to obtain documentations in several languages.
This thesis deals with the development of the described website. First a requirements analysis shows
the requirements for the website. By means of the requirements the website will be modeled. The
focal point of this thesis will be the modelling. All models necessary for the realisation of the
website are shown. Based on the modelling the most important parts of a possible implementation
are discussed. At last legal issues for running the project are discussed as well.
It will be shown that besides comprehensive technical and linguistic skills as well as experience in
mountaineering, basic skills in the domains of accounting and laws concerning the internet are
necessary for the development of the project. The realisation of the website will emerge as a multi
disciplinary project in the exciting domain of mountaineering.
1) http://www.AlpinImageS.com/ iv

Inhaltsverzeichnis
1 Einführung.........................................................................................................................................1
1.1 Motivation..................................................................................................................................1
1.2 Aufgabenstellung.......................................................................................................................3
1.3 Begriffe und Definitionen..........................................................................................................5
1.4 Lösungsstrategie........................................................................................................................6
2 Anforderungsanalyse.........................................................................................................................7
2.1 Funktionale Anforderungen.......................................................................................................7
2.1.1 Empfang und Startseite......................................................................................................7
2.1.2 Kauf von Dokumentationen...............................................................................................8
2.1.3 Bereich für Mitglieder........................................................................................................8
2.1.4 Verwaltungsbereich..........................................................................................................10
2.1.5 Touren­Update.................................................................................................................11
2.1.6 Alben­Update...................................................................................................................13
2.2 Nicht­funktionale Anforderungen............................................................................................14
2.2.1 Internationalisierung........................................................................................................14
2.2.2 Schutz des Dokumentationsmaterials..............................................................................14
2.2.3 Sicherheitsaspekte............................................................................................................16
3 Modellierung...................................................................................................................................19
3.1 Modellierung ausgewählter Use Cases....................................................................................19
3.1.1 Tourenmenü.....................................................................................................................19
3.1.2 Tour anzeigen...................................................................................................................20
3.1.3 Album anzeigen...............................................................................................................22
3.1.4 Dokumentation kaufen.....................................................................................................23
3.1.5 Login................................................................................................................................24
3.1.6 Anmelden.........................................................................................................................25
3.1.7 Passwortabfrage...............................................................................................................28
3.2 Klassenmodellierung...............................................................................................................33
3.2.1 Benutzergruppen..............................................................................................................33
3.2.2 Tourtypen.........................................................................................................................37
3.2.3 Klassenbeziehungen einer Tour.......................................................................................41
3.2.4 Klassenbeziehungen eines Albums..................................................................................44
3.2.5 Übersetzer........................................................................................................................45
3.2.6 Touren­ und Albenberechtigungen...................................................................................46
3.2.7 Aufladung des Guthabens................................................................................................48
3.2.8 Gebiete.............................................................................................................................48
3.2.9 PDF­Dokumente..............................................................................................................50
3.2.10 Werber­Domains............................................................................................................51
3.2.11 Ausgewählte Hilfsklassen..............................................................................................51
3.2.12 Buchhaltung...................................................................................................................52
3.3 Softwarepakete.........................................................................................................................56
3.3.1 Grundgerüst der Softwarepakete......................................................................................56
3.3.2 Aufbau eingebundener Softwarepakete...........................................................................56
3.3.3 Aufbau der Serverskripte.................................................................................................58
3.3.4 Inhalte des Tourenmenüs.................................................................................................59
3.3.5 Bereich für Mitglieder......................................................................................................60
4 Ausgewählte Bereiche der Implementierung...................................................................................62
4.1 Systemarchitektur....................................................................................................................62
v

4.2 Internationalisierung ­ Übersetzung der Plattform..................................................................65
4.3 Fotoverwaltung........................................................................................................................67
5 Benutzungstests...............................................................................................................................71
5.1 Allgemeine Benutzungsprobleme............................................................................................71
5.2 Spezielle Benutzungsprobleme auf der realisierten Internetseite............................................75
5.3 Sicherheit versus Benutzerfreundlichkeit................................................................................76
6 Rechtliche Grundlagen....................................................................................................................78
6.1 Providerhaftung.......................................................................................................................78
6.2 Geschäfte im Internet...............................................................................................................80
6.3 Versand von Werbemails.........................................................................................................82
6.4 Datenschutz und Urheberrecht.................................................................................................83
6.5 Tätigkeit als Autor...................................................................................................................84
7 Zusammenfassung und Ausblick.....................................................................................................86
7.1 Ergebnisse der Arbeit...............................................................................................................86
7.2 Ausblick...................................................................................................................................88
8 Literatur...........................................................................................................................................89
vi

1 Einführung 30. August 2006
1 Einführung
Der Bergsport erfreut sich in den letzten Jahren zunehmender Beliebtheit. Der Erlebnis­ und
Erholungswert, das Bewältigen neuer Herausforderungen, das Begegnen von und der Umgang mit
alpinen Gefahren, die persönliche Entwicklung und Selbsterkenntnis und viele weitere
Einflussfaktoren auf alpinen und hochalpinen Touren sind für viele Wanderer und Bergsteiger
zentrale Motivationsquellen, solche Touren zu bestreiten. Der Erlebniswert einer alpinen Tour ist
dabei für die meisten Tourengeher die Hauptmotivation für das Begehen der Tour.
Um die Erlebnisse auf einer Tour tatsächlich genießen zu können, ist eine genaue Tourenplanung
von großer Wichtigkeit, in der mögliche Situationen bereits im Vorhinein durchdacht werden.
Unzureichende Vorbereitung führt im alpinen Bereich nur allzuschnell zu unliebsamen
Überraschungen, aus denen sich ernsthafte Gefahren entwickeln können.
Für Tourengeher ist oftmals Bildinformation über eine Tour von hohem Interesse, weil dadurch die
Tourenplanung erheblich unterstützt wird. Die Orientierung vor Ort sowie die Einschätzung von
Schlüsselstellen in der Tour werden durch vorher bekanntes Bildmaterial wesentlich erleichtert. In
der vorliegenden Arbeit wird die Entwicklung der Bergsportplattform [AIS] gezeigt, deren
Herausgeber ich bin. Die Plattform ermöglicht den Verlag von fotounterstützten Dokumentationen
alpiner Touren und stellt dem Tourengeher somit ausreichendes Bildmaterial für eine umfassende
Tourenplanung zur Verfügung.
1.1 Motivation
Ein gute Tourenplanung ist die Grundlage für tolle Erlebnisse und für die Sicherheit auf einer
alpinen Tour. Wie eine Tourenplanung für alpine Touren am besten ganzheitlich durchgeführt wird,
ist Diskussionsthema vieler alpiner Vereine und vieler Fachleute. Einen guten Anhaltspunkt für die
Planung von Touren im alpinen Gelände bietet u.a. der Alpinlehrplan für Hochtouren [AlLp01].
Laut diesem Lehrplan kommt in der Vorbereitung Fachliteratur zur Anwendung, die über den
Verlauf der Tour, deren Schwierigkeiten und Schlüsselstellen genaue Informationen gibt.
Fachliteratur
Als Fachliteratur zu alpinen Touren kamen in den letzten Jahren immer mehr Bücher im Alpenraum
(Österreich, Schweiz, Italien, Frankreich) heraus. Im wesentlichen können hier zwei Arten von
Büchern unterschieden werden. Zum einen textbasierte Tourenbücher, die Touren in Textform
beschreiben, zum anderen Bildbände, die Bildmaterial über bestimmte Gebiete präsentieren.
Tourenbücher in Textform haben oft den Nachteil, dass diese kaum oder nur ungenügend
Fotomaterial beinhalten. Aufgrund der beschränkten Seitenanzahl und der erhöhten Druckkosten in
Farbe enthalten fast alle derartigen Tourenbücher wenn überhaupt maximal 1­2 Fotos pro Tour.
Eines der ersten Standardwerke für die Ostalpen war [MaKo02]. Dieser Führer beinhaltet
ausgezeichnete Texte über die beschriebenen Touren, jedoch fast keine Fotos zur jeweiligen Tour.
Übersichtsfotos fehlen praktisch gänzlich. Der Tourengeher erhält somit leider keine wesentliche
Bildinformation über die Touren. Ähnlich arbeiten diverse Alpenvereinsführer, nur dass diese nicht
so genau geschrieben sind. Alpenvereinsführer enthalten eine Unmenge von Touren, zu denen
jedoch meistens nur ein paar Zeilen Text zu finden sind.
Bildbände beeindrucken meist durch grandiose und stimmungsvolle Landschaftsaufnahmen und
Walter Sunk 1

1 Einführung 30. August 2006
verlocken somit sehr, das dokumentierte Gebiet selbst einmal zu besuchen. Bildbände eigenen sich
sehr gut dazu, sich einen Gesamteindruck über das Gebiet und die Landschaft zu machen.
Beispielsweise beinhaltet [PeDo03] beeindruckende Landschaftsaufnahmen von allen 4000ern der
Alpen. Nachdem man derartige atemberaubende Aufnahmen gesehen hat, muss man als begeisterter
Bergsteiger das Gebiet einfach einmal selbst besuchen. Der Nachteil von Bildbänden ist jedoch
offensichtlich. Sie vermitteln leider meist nur Eindrücke über die Landschaft, eigenen sich jedoch in
der Regel nicht als Führerliteratur. Oft verweisen Bildbände auch direkt auf weitere Literatur (wie
dies z.B. in [PeDo03] der Fall ist), die zum Durchführen der Tour unbedingt empfohlen wird.
Zudem sind die Kosten von Bildbänden verglichen mit Büchern in Textform aufgrund der farbigen
Fotos klarerweise um einiges höher. Bildbände haben außerdem generell mit dem Problem zu
kämpfen, dass man in einem Buch eben nicht beliebig viele Fotos abbilden kann. Nehmen wir an,
wir wollten für jeden Normalweg auf alle 4000er der Alpen (nur) 30 Fotos abbilden. Offiziell sind
82 Gipfel als eigenständige 4000er anerkannt. Unter der Annahme, dass ein Foto eine Seite Platz
braucht, kämen wir dann auf 82*30 = 2460 Seiten. Aus Platz­ und Kostengründen ist dies in einem
Buch kaum realisierbar. Die weitaus schwierigere Aufgabe würde überdies darin bestehen, zu jeder
dieser Touren erst einmal die Fotos (bei angebrachten Wetterverhältnissen) zu bekommen.
Ansätze im Internet
Mit der Zeit haben sich einige Internetplattformen gebildet, die Dokumentationen alpiner Touren
anbieten. In der Regel funktionieren diese Plattformen so, dass ein jeder Tourengeher seine Tour
eintragen kann. Hintergrund dabei ist, möglichst viele Tourendokumentationen zu erhalten. Genau
darin steckt jedoch das Problem solcher Plattformen. Ein jeder kann alles schreiben. Es gibt
keinerlei Qualitätskriterien. Oftmals ist eine Überarbeitung der Administration erforderlich, um die
Tourendokumentationen in einem stilistisch einwandfreien Text wiederzugeben. Meist sind die
Touren wieder nur in Worten beschrieben, weil die Aufbereitung und die Verarbeitung von Fotos zu
zeitaufwendig für den Verfasser ist. Falls Fotos überhaupt vorhanden sind, dann werden diese
zumeist in keinerlei Bezug zum Text gebracht. In der Regel sind auch keine Karten vorhanden. Dies
geschieht entweder aus Urheberrechtsgründen oder einfach deshalb, weil es zu aufwendig für den
Verfasser ist, eine Karte selbst zu erstellen.
Entstehung des Projektes [AIS]
Als aktiver Tourengeher bin ich selbst stets auf der Suche nach genauen Informationen über meine
bevorstehenden Touren. Eine genaue Tourenplanungen ist für mich stets von großer Wichtigkeit
und bildet für mich eine ganz wesentliche Voraussetzung zur erfolgreichen Durchführung meiner
bevorstehenden Touren.
In der Regel werden Gletschertouren aufgrund der Spaltengefahr immer zu zweit am Seil
durchgeführt. Ich habe mit Stefan Lamprechter einen guten Bergkammeraden gefunden, mit dem
ich die meisten meiner Touren unternommen habe. Wir haben uns zur Tourenplanung daher stets
Informationen von Bekannten, aus Büchern und Internet besorgt. Das Suchen von Informationen
war dabei immer extrem zeitaufwendig. Trotz unserer Recherchen haben wir die für uns optimale
Tourendokumentation nie wirklich gefunden. Wir haben uns gefragt, warum?
Wie bereits besprochen waren Texte aus Tourenbüchern zwar stets sehr gut verfasst, doch in unserer
Praxis hat sich herausgestellt, dass für uns dokumentiertes Fotomaterial zu einer Tour noch viel
wichtiger ist. Wir kamen durch Bekannte zu sehr gutem Fotomaterial von diversen Touren. Dadurch
Walter Sunk 2

1 Einführung 30. August 2006
konnten wir uns schon im Vorhinein eine Vorstellung von der gesamten Tour verschaffen. Die
Fotos ermöglichten uns Einsicht in Schlüsselstellen sowie eine wesentlich erleichterte Orientierung
im Gelände. Im weiteren lösten die Fotos dieser Touren bei uns eine solche Begeisterung aus,
sodass wir eigentlich sofort aufbrechen wollten.
Im Zuge dessen kam unsere erste Idee. Wir dachten uns, wir könnten Autoren die Möglichkeit
geben, Dokumentationen mit vollständigem Fotomaterial zu veröffentlichen. Und dieses
Fotomaterial müsste für einen jeden Tourengeher gleich nach Verfassen der Dokumentation
zugänglich sein. Gleichzeitig war uns klar, dass Autoren für derartig qualitativ hochstehende
Dokumentationen entsprechend entlohnt werden müssen. Sie sind nicht nur ständig allen alpinen
Gefahren ausgesetzt, sondern liefern durch ihre Dokumentationen eine wesentliche Grundlage zur
Auswahl und erfolgreichen eigenständigen Durchführung alpiner Touren. Die Lösung lag auf der
Hand: ein Online Redaktionssystem, in dem Autoren Ihre Dokumentationen selbständig zu eigenen
Preisen direkt verkaufen können. Der erste Grundstein zu dem Projekt [AIS] war gelegt.
Gebirge gibt es in vielen Ländern, in jedem dieser Länder werden unterschiedliche Sprachen
gesprochen. Begeisterte Alpinsportler möchten jedoch die Gebirge auf der ganzen Welt kennen
lernen, ohne dabei durch sprachliche Barrieren eingeschränkt zu sein. Somit dachten wir uns, es
wäre äußerst nützlich, wenn es eine mehrsprachige internationale Plattform gäbe. Tourengeher aus
allen alpinen Staaten haben dadurch etwa die Möglichkeit, Tourendokumentationen von Autoren
vor Ort zu erwerben. Autoren ihrerseits haben wieder die Möglichkeit, Tourendokumentationen von
Touren vor Ort ständig zu erneuern, wodurch die Qualität der Dokumentationen stets auf hohem
Niveau bleibt. Der zweite Grundstein zu [AIS] war gelegt.
Mein Tourenfreund und ich haben aufgrund dieser beiden Grundsteine beschlossen, alle Vorteile
der bisher diskutierten Dokumentationsmethoden von alpinen Touren zu vereinen, zu verbessern
und auszubauen und damit die Bergsportplattform [AIS] zu gründen. Ich selbst bin zuständig für die
technische Umsetzung, habe [AIS] im Zuge der vorliegenden Arbeit realisiert und bin somit
Herausgeber der Internetseite. Stefan Lamprechter ist für die englische und Veronika Zenz für die
französische Übersetzung zuständig.
1.2 Aufgabenstellung
Nach dem Gründungsentschluss wurde folgende Aufgabenstellung entwickelt.
Verlag von Touren und Tourenalben – der erste Grundstein
Mit der Bergsportplattform [AIS] soll ein Verlagssystem geschaffen werden, dass den Verlag von
fotounterstützten Dokumentationen alpiner Touren ermöglicht. Autoren sollen auf der
Bergsportplattform derartige Dokumentationen online erstellen, jederzeit warten und selbständig zu
eigenen Preisen direkt an Kunden verkaufen können. Die Dokumentationsinhalte einer Tour sollen
dabei sowohl online als auch in Form von PDF­Dokumenten bezogen werden können. Überdies
sollen Autoren ausgewählte Touren zu Tourenalben zusammenfassen können. Beim Erwerb eines
Tourenalbums werden dann alle Tourendokumentationen, die sich in diesem Album befinden,
erworben. Autoren sollen die Möglichkeit haben, Tourenalben gemeinsam zu erstellen.
Internationalität ­ der zweite Grundstein
Die Plattform soll mehrsprachig ausgelegt werden. Als Basissprachen sollen Deutsch, Englisch und
Walter Sunk 3

1 Einführung 30. August 2006
Französisch verfügbar sein.
Schutz des Dokumentationsmaterials
PDF­Dokumente und Fotos sollen nach Möglichkeit urheberrechtlich vor unerlaubter
Vervielfältigung und unerlaubter Veröffentlichung geschützt werden. Auf allen Fotos muss der
Urheber erkennbar sein und auf das Urheberrechtsgesetz durch das Copyright­Logo hingewiesen
werden. Es sind weitere Möglichkeiten zum Schutz vor unerlaubter Vervielfältigung und
unerlaubter Veröffentlichung zu diskutieren und zu implementieren.
Rechtliche Grundlagen
Die rechtlichen Grundlagen zum Betreiben einer derartigen Bergsportplattform sollen recherchiert
und dargelegt werden. Für Internetseiten, auf denen Produkte verkauft werden, gilt insbesondere das
E­Commerce Gesetz. Insbesondere sollen die auf die Plattform zutreffenden Bestimmungen dieses
Gesetztes eingehalten werden.
Übersetzung von Dokumentationen
Autoren sollen ihre Dokumentationen in andere Sprachen übersetzen lassen können. Zum
Übersetzen einer Dokumentation soll ein Autor einem von ihm gewählten Übersetzer Zugriff auf
die übersetzbaren Teile der Dokumentation gewähren können.
Ausgliederung des Aufladesystems und seiner Voraussetzungen
Dokumentationen sollen ab 1EUR netto käuflich erwerbbar sein. Aufgrund geringerer
Überweisungsspesen muss ein Kunde zuerst ein Mindestguthaben von 5EUR (brutto) aufladen,
danach kann der Kunde dann Dokumentationen erwerben. Aufgrund der Komplexität und des
Umfangs der gesamten Plattform wurde das Aufladesystem mitsamt seinen Voraussetzungen
(Session Management System, Log In System, Brute Force Abwehr, Secure Codes (Captchas, siehe
auch [CMU])) in der Praktikumsarbeit [WaSu06] realisiert. Die Arbeit [WaSu06] befasst sich u.a.
auch mit allen relevanten sicherheitskritischen Aspekten im Aufladesystem.
Werbung durch Werber
Es soll die Möglichkeit bestehen, dass Personen oder juristische Personen Werbung für die
Bergsportplattform machen. Solche Personen oder juristische Personen werden in dieser Arbeit
Werber genannt. Kunden können also durch Werber geworben werden. Werber werden von den
Einkäufen der Kunden bezahlt. Es sind geeignete Maßnahmen zu implementieren, um den Werber
eines Kunden bestimmen zu können.
Basisinhalt an Dokumentationen
Als Basisinhalt soll auf der Plattform ein Osttirol Wander­ und Hochtourenführer sowie ein kleiner
Zentralpyrenäen Wanderführer herausgegeben werden. Die beschriebenen Führer werden dabei in
Form von Tourenalben veröffentlicht.
Umfang an Tourtypen
Mit Beginn des Sommers 2006 sollen Wanderungen und Hochtouren dokumentiert werden können,
Walter Sunk 4

1 Einführung 30. August 2006
andere Tourtypen (z.B. Skitouren, Skihochtouren, Schneeschuhwanderungen) sollen bereits in der
Modellierung berücksichtigt werden, brauchen jedoch noch nicht implementiert zu sein.
1.3 Begriffe und Definitionen
Tour, Tourendokumentationen
Eine Tour ist eine Unternehmung im freien Gelände oder im Gebirge. An manchen Stellen wird als
Abkürzung für den Begriff Tourendokumentation lediglich das Wort "Tour" verwendet (z.B. "Tour
kaufen" für "Tourendokumentation kaufen").
Album, Tourenalbum
Beide Begriffe werden aus der Sicht eines Benutzers gleichwertig verwendet. Aus Benutzersicht ist
ein Album bzw. ein Tourenalbum eine Zusammenstellung ausgewählter Tourendokumentationen.
In der Modellierung besteht jedoch ein Unterschied. Im Modell versteht man unter einem
Tourenalbum vereinfacht das Hinzufügen von Touren zu einem Album. Ein Album kann daher auch
alleine existieren, ohne Touren zu beinhalten. Ein Tourenalbum hingegen muss Touren beinhalten.
Dokumentation
Eine Dokumentation ist entweder eine Tourendokumentation oder ein Tourenalbum.
Autor bzw. Alpinautor:
Beide Begriffe werden gleichwertig verwendet. Ein Autor bzw. Alpinautor ist ein Schriftsteller, der
Dokumentationen direkt an Kunden verkauft.
Anmeldung, Registrierung
Beide Begriffe werden gleichwertig verwendet. Unter der Anmeldung (oder Registrierung) auf der
Bergsportplattform wird der Prozess zur Eröffnung eines Kundenaccounts verstanden. Mit dem
Kundenaccount kann der Kunde dann Dokumentationen erwerben. Bei der Anmeldung werden
persönliche Daten des Kunden aufgenommen, die vertraulich behandelt werden. Im Zuge der
Anmeldung kann der Kunde seinen Benutzernamen und sein Passwort selbst auswählen.
Mitgliedsbereich, Bereich für Mitglieder
Beide Begriffe werden gleichwertig verwendet. Sie bezeichnen jenen Bereich auf der
Bergsportplattform, der nur von angemeldeten Benutzern betreten werden kann.
Sommersaison, Winter­ und Frühjahrssaison:
• Sommersaison: 01.05. bis 31.10. des gleichen Jahres
• Winter­ und Frühjahrssaison: 01.11. bis 31.04. des Folgejahres
Saison
Eine Saison bezeichnet entweder eine Sommersaison oder eine Winter­ und Frühjahrssaison.
Walter Sunk 5

1 Einführung 30. August 2006
1.4 Lösungsstrategie
In Kapitel 2 wird zunächst eine Anforderungsanalyse unternommen, welche die notwendigen
funktionalen und nicht­funktionalen Anforderungen an die Bergsportplattform aufzeigt. Funktionale
Anforderungen werden in Form von Use Cases dokumentiert. Daran anschließend werden die
wichtigsten nicht­funktionalen Anforderungen in Textform dargestellt.
Aufbauend auf den funktionalen und nicht­funktionalen Anforderungen wird dann in Kapitel 3 die
Bergsportplattform modelliert. Die Modellierung soll dabei jederzeit eine Implementierung der
Bergsportplattform ermöglichen. Daher bildet auch die Modellierung den Schwerpunkt der
vorliegenden Arbeit. Zu Beginn der Modellierung werden komplexere Use Cases modelliert, die
einer genaueren Beschreibung bedürfen. Danach werden in einer Klassenmodellierung alle
notwendigen Klassen beschrieben und nachfolgend die notwendigen Softwarepakete zur
Umsetzung der Plattform diskutiert. Sämtliche zum Einsatz kommende Diagramme in der
Modellierung sind nach dem UML 2 Standard gemäß [UML205] erstellt. In Einzelfällen kommt es
vor, dass bestimmte Notationen nicht vollkommen dem UML 2 Standard entsprechen. Die ist
bedingt durch die verwendeten Tools zur Erzeugung der Diagramme.
Auf Basis der zugrunde gelegten Modellierung aus Kapitel 3 werden in Kapitel 4 ausgewählte und
wichtige Bereiche der Implementierung der Plattform besprochen. Dabei wird zuerst eine
Systemarchitektur entwickelt. Da die Plattform mehrsprachig sein soll, wird nachfolgend die
Übersetzung der Plattform gezeigt. Der wohl wichtigste Punkt der Implementierung ist die
Fotoverwaltung, die die Fotos der dokumentierten Touren verwalten und bereit stellen soll.
Um zu testen, wie unterschiedliche erfahrene Internetbenutzer mit der Plattform umgehen, werden
Benutzungstests unternommen, deren wichtigste Ergebnisse in Kapitel 5 dargestellt sind. Es werden
Maßnahmen besprochen, wie eher unerfahrenen Internetbenutzern bei wichtigen Interaktionen
geholfen werden kann. Den Abschluss bildet Kapitel 6 mit einer Diskussion der rechtlichen
Grundlagen für das Projekt.
Walter Sunk 6

2 Anforderungsanalyse 30. August 2006
2 Anforderungsanalyse
In diesem Kapitel beschäftigen wir uns mit den funktionalen und nicht­funktionalen Anforderungen
an das Verlagssystem. Die funktionalen Anforderungen werden dabei in Abschnitt 2.1 in der Regel
durch Use Cases beschrieben, die vom jeweiligen Benutzer der Plattform abhängen. Zu den
Benutzergruppen, die direkt mit der Internetseite interagieren, zählen gemäß Abschnitt 3.2.1
Besucher, Kunden, Autoren, Autorenbetreuer, Übersetzer, Werber und Administratoren. Die nichtfunktionalen
Anforderungen werden anschließend in Abschnitt 2.2 behandelt. Diese beschreiben
wichtige Umstände, unter denen die Plattform zu arbeiten hat.
2.1 Funktionale Anforderungen
2.1.1 Empfang und Startseite
Empfang
Beim Empfang auf der Internetseite soll ein Benutzer die Sprachauswahl treffen. Nach der
Sprachauswahl muss der Benutzer aus rechtlichen Gründen die Allgemeinen Geschäftsbedingungen
und den Haftungsausschluss akzeptieren. Der Haftungsausschluss schließt die Bergsportplattform
im Falle von Bergsportunfällen im Zusammenhang mit der Plattform von der Verantwortung aus.
Natürlich muss der Benutzer auch beide Dokumente dazu lesen können. Wenn der Benutzer
akzeptiert, darf er die Willkommensseite betreten und kann dort z.B. zu den Dokumentation gehen.
Die Willkommensseite ist auch gleichzeitig die Startseite der Plattform. Abbildung 2.1.1 stellt
diesen einzelnen Use Case als Aktivitätsdiagramm dar.
Startseite
Abbildung 2.1.1: Darstellung des Use Case Empfang
Auf der Startseite haben Benutzer als erstes die Möglichkeit, kostenfreie Beispieltouren einzusehen.
Eine Beispieltour zeigt den vollen Funktionsumfang und Inhalt einer Tourendokumentationen. Zu
Walter Sunk 7

2 Anforderungsanalyse 30. August 2006
den weiteren Bereichen, die von der Startseite aus erreichbar sind, zählen das Tourenmenü, der
Infobereich und das Login. Abbildung 2.1.2 zeigt die auftretenden Use Cases.
Im Tourenmenü bekommt der Benutzer Infos über neue Touren und Tourenalben, kann einzelne
bereits bestehende Touren und Tourenalben auswählen und nach Dokumentationen suchen. Im
Infobereich erhält der Benutzer Projektinformationen, rechtliche Informationen (dazu zählen der
Haftungsausschluss und die Allgemeinen Geschäftsbedingungen), Kontaktdaten und eine
Feedbackmöglichkeit zur Internetseite. Im Login Bereich kann sich der Benutzer entweder
einloggen (wenn er bereits ein Mitglied ist), einen neuen Kundenaccount eröffnen (wenn er noch
kein Mitglied ist) oder die Interaktion zur Passwortabfrage starten, falls der Benutzer sein Passwort
vergessen hat.
Abbildung 2.1.2: Use Cases auf der Startseite
2.1.2 Kauf von Dokumentationen
Nachdem sich ein Benutzer angemeldet hat, wird er automatisch zum Kunden und kann
Dokumentationen, also Touren oder Alben kaufen. Abbildung 2.1.3 zeigt die beiden entsprechenden
Use Cases. Diese werden in Abschnitt 3.1.4 im Detail modelliert.
Abbildung 2.1.3: Use Cases zum Kauf von Dokumentationen (Touren oder Alben)
2.1.3 Bereich für Mitglieder
Der Mitgliedsbereich unterteilt sich je nach Benutzergruppe in folgende 5 weitere Bereiche:
Kundenbereich, Autorenbereich, Autorenbetreuerbereich, Übersetzerbereich, Werberbereich. Betritt
ein Benutzer den Mitgliedsbereich, dann hat er Zugang zu den Bereichen jener Benutzergruppen,
denen er angehört. Abbildung 2.1.4 zeigt die verschiedenen Mitgliedsbereiche.
Im Kundenbereich können Kunden Neuigkeiten lesen, gekaufte Touren und Alben beziehen, ihre
Walter Sunk 8

2 Anforderungsanalyse 30. August 2006
Abbildung 2.1.4: Use Cases im Mitgliedsbereich
Umsätze einsehen, ihr Kundenprofil ändern und ihr Guthaben aufladen. Das Aufladen des
Guthabens ist gemäß Abschnitt 1.2 nicht Gegenstand dieser Arbeit, kann jedoch in [WaSu06]
Walter Sunk 9

2 Anforderungsanalyse 30. August 2006
nachgelesen werden. Die Möglichkeit zur Änderung des Kundenprofils ist aus rechtlicher Sicht von
Bedeutung, da ein Kauf einer Dokumentation ein Kaufvertrag zwischen dem Kunden und dem
Autor ist. Notwendig für die Gültigkeit von Kaufverträgen sind korrekte Angaben der beteiligten
Personen. Daher müssen sowohl Autor als auch Kunde ihre Profile updaten können.
Im Autorenbereich kann ein Autor Touren und Alben (auch Partneralben) updaten, sein
Autorenprofil ändern und seine Umsätze sowie seine Verkaufsstatistik einsehen. Die Use Cases
Tour updaten und Album updaten bestehen tatsächlich aus einer Vielzahl einzelner Use Cases.
Zwecks Übersicht werden diese Use Cases in den Abschnitten 2.1.5 und 2.1.6 extra besprochen.
Übersetzer können im Übersetzerbereich Touren und Alben übersetzen sowie ihr Übersetzerprofil
ändern. Es ist darauf zu achten, dass Übersetzer auch wirklich nur zu übersetzende Daten in den
vom Autor freigegebenen Sprachen ändern können.
Autorenbetreuer betreuen Autoren. Im Autorenbetreuerbereich können Autorenbetreuer Touren und
Alben für ihre Autoren anlegen. Ein Autorenbetreuer kann alle Aktionen durchführen, die auch der
zu betreuende Autor durchführen kann. Zu diesem Zweck muss der Betreuer zuerst den
entsprechenden Autor auswählen. Betreuer erhalten eine Betreuerprovision. In ihrem Bereich
können sie diese einsehen. Im weiteren können Betreuer natürlich auch ihr Profil ändern.
Werber können in ihrem Bereich ihre Werberprovision einsehen und ihr Profil ändern.
2.1.4 Verwaltungsbereich
Der Verwaltungsbereich kann nur von Administratoren betreten werden. Abbildung 2.1.5 zeigt die
entsprechenden Use Cases, die von Administratoren durchgeführt werden.
Abbildung 2.1.5: Use Cases im Verwaltungsbereich
Die Aufgaben von Administratoren im Verwaltungsbereich sind Berechtigungen zu setzen,
Walter Sunk 10

2 Anforderungsanalyse 30. August 2006
Werbern den geworbenen Kunden zuzuordnen, die Buchhaltung zu prüfen und durchzuführen sowie
die Datenbankadministration. Zu jedem Saisonende müssen die Buchhaltung abgeschlossen und die
Verdienste ausbezahlt werden.
Ein besonderes Service für Autoren ist die Datenbank. Autoren können sämtliche Daten, die sie für
ihre Dokumentationen benötigen (z.B. Gipfel (Ziele), Hütten (Ziele), Talorte, etc.) aus der
Datenbank beziehen. Dies bedeutet für Autoren nicht nur eine Erleichterung beim Dokumentieren,
sondern gewährleistet auch, dass Dokumentationsdaten wie z.B. die Höhe oder der Name eines
Berges in unterschiedlichen Dokumentationen gleich sind.
Wie in [WaSu06] beschrieben können Kunden ihr Guthaben mittels Banküberweisung aufladen.
Administratoren sind dafür zuständig, bei einer Aufladung mittels Überweisung das aufgeladene
Guthaben dem jeweiligen Kundenaccount anzurechnen (Use Case Kundenguthaben aufladen).
2.1.5 Touren­Update
Alle Touren auf der Bergsportplattform können wie in Abbildung 2.1.6 gezeigt upgedatet werden.
Dadurch besteht die Möglichkeit, Touren regelmäßig zu warten. Dies ist ein besonders wichtiges
Qualitätskriterium, weil dadurch Touren auf einem aktuellen Stand gehalten werden können.
Autoren, die Touren regelmäßig begehen (z.B. Autoren, die vor Ort leben), können dadurch stets
neueste Informationen zu ihren Touren bereitstellen.
Wie in Abschnitt in 3.1.2 diskutiert besteht eine Tour im wesentlichen aus den Komponenten
Übersicht, Fotos, Karten und Beschreibung. Außerdem können Autoren für jede Tour einen oder
mehrere Übersetzer bestimmen. Im weiteren müssen Autoren die Öffentlichkeitsrechte für ihre
Touren bestimmen. Damit die Öffentlichkeitsrechte aktiv werden, muss der jeweilige Betreuer des
Autors seine Zustimmung erteilen.
In der Übersicht einer Tour können neben deren Basisdaten (Name, Charakteristik, Länge, Höhe,
etc.) deren Tourenziele, Tourenstützpunkte und Tourentalorte mit Hilfe der Datenbank upgedated
werden. Außerdem kann der Autor jede Tour zu einem eigenen oder zu einem Album eines
Partnerautors hinzufügen.
Das Herzstück einer jeden Tourendokumentation sind deren Fotos und die Verlinkung der Fotos mit
dem Text, der Karte und mit anderen Fotos. Um neue Fotos zu einer Tour hinzuzufügen, müssen
diese zuerst einmal auf den Server hinaufgeladen werden. Dazu erhält der Autor einen FTP­Zugang
zum Webserver. Aus Sicherheitsgründen bietet der Server die Verschlüsselung TLS an, dadurch ist
gewährleistet, dass FTP­Benutzername, FTP­Passwort sowie die Fotos des Autors bei der
Übertragung nicht im Klartext aufgezeichnet werden können. Nachdem der Autor die Fotos
hinaufgeladen hat, muss er sie „einchecken“. Beim sogenannten Check In werden Fotos auf ihre
Gültigkeit überprüft. Verläuft der Check In positiv, so kann der Autor Fotos zur Tour hinzufügen.
Es besteht die Möglichkeit, die Anzeige­Reihenfolge von Fotos innerhalb derselben Tour jederzeit
zu ändern. Im weiteren kann jedes Fotos beschriftet werden.
Eine Besonderheit ist, dass Fotos untereinander (mit sogenannten Fotolinks), Fotos mit Karten (mit
so genannten Kartenfotolinks) und Fotos aus dem Beschreibungstext heraus (beim Updaten des
Tourenverlaufs) verlinkt werden können. Die entsprechenden Use Cases finden sich in den 3
entsprechenden Subsystemen.
Karten werden im Gegensatz zu Fotos direkt über HTTP auf den Server hinaufgeladen. Eine
Gültigkeitsprüfung der jeweiligen Karte erfolgt direkt nach dem Hinaufladen. Jede Karte kann
natürlich einzeln beschriftet werden.
Walter Sunk 11

2 Anforderungsanalyse 30. August 2006
Abbildung 2.1.6: Use Cases beim Touren­Update
Die Beschreibung einer Tour besteht aus 3 Komponenten, und zwar aus der „Anreise und Zufahrt“,
dem „Tourenverlauf“ und den „Erlebnissen und Eindrücken“. Jede Komponente kann einzeln
upgedatet werden, wobei in den Tourenverlauf Links zu den jeweiligen Fotos eingebaut werden
können. Ein Benutzer kann dann die Tour anhand des Tourenverlaufs mit den verlinkten Fotos vom
Start bis zum Ziel virtuell durchgehen.
Öffentlichkeitsupdate
Im Öffentlichkeitsupdate kann die Tour publiziert und veröffentlicht werden. Es wird also zwischen
den Begriffen „Publikation“ und „Veröffentlichung“ unterschieden. Publikation bedeutet, der
Name der Tour wird bei einer Suche gefunden. Veröffentlichung bedeutet, dass die öffentlichen
Walter Sunk 12

2 Anforderungsanalyse 30. August 2006
Basisdaten der Tour angezeigt werden. Die Veröffentlichung einer Tour erfolgt in einer bestimmten
Sprache. Ist eine Tour z.B. publiziert, jedoch nicht veröffentlicht, dann wird die Meldung „Tour in
Bearbeitung“ angezeigt. Benutzer sehen dadurch, dass die Tour zumindest existiert und können in
ein paar Tagen zurückkommen um zu sehen, ob die Tour bereits verfügbar ist. Die Unterscheidung
zischen „publizieren“ und „veröffentlichen“ macht z.B. dann Sinn, wenn ein Autor die Tour
kurzfristig überarbeiten möchte.
Ist eine Tour veröffentlicht, dann wird sie jedoch noch nicht verkauft. Der Verkauf einer Tour muss
extra freigegeben werden. Dies ist z.B. notwendig, wenn ein Autor eine Tour nicht mehr anbieten
möchte, die Tour aufgrund von vertraglichen Bestimmungen jedoch noch von Kunden verwendet
werden darf. Alle Öffentlichkeitsrechte werden erst dann wirksam, wenn der jeweilige
Autorenbetreuer seine Zustimmung erteilt hat. Das ist notwendig, damit Qualitätskriterien überprüft
werden können und somit eingehalten werden.
2.1.6 Alben­Update
Genau wie alle Touren können auch alle Alben (gemäß Abbildung 2.1.7) upgedatet werden (aus
welchen Teilen ein Album besteht, wird in Abschnitt 3.1.3 gezeigt).
Abbildung 2.1.7: Use Cases beim Alben­Update
Bei Alben kommt jedoch noch hinzu, dass diese im Team verfasst werden können. Für ein im Team
verfasstes Album muss ein hauptverantwortlicher Autor gewählt werden. Der hauptverantwortliche
Walter Sunk 13

2 Anforderungsanalyse 30. August 2006
Autor kann Partnerautoren suchen und diese Partnerautoren zum Album hinzufügen. Die
hinzugefügten Partnerautoren können daraufhin Touren zu diesem Album hinzufügen.
Durch Teamarbeit können Tourenalben relativ schnell und einfach herausgegeben werden. Ein
Autor braucht eben nicht alle Touren des Albums selbst gehen, sondern kann sich die Touren mit
anderen Autoren teilen. Dies hat den Vorteil, dass dadurch die „Time­to­Market“ wesentlich
reduziert werden kann. Außerdem können Touren in mehrere Tourenalben aufgenommen werden.
Es besteht daher die Möglichkeit, quasi aus einem Topf von Touren unterschiedlichste Tourenalben
zusammenzustellen, ohne dabei Touren doppelt gehen zu müssen. Dadurch können unterschiedliche
Zielgruppen angesprochen werden.
Zum Album können Impressionsfotos über HTTP hinaufgeladen werden. Impressionsfotos sollen
Stimmungsbilder des Tourenalbums wiedergeben und Vorfreude bei Tourengehern wecken.
Das Übersichtsupdate, das Öffentlichkeitsupdate und die Übersetzung der Albumdaten
funktionieren analog zum Touren­Update wie in Abschnitt 2.1.5 beschrieben. Für jedes
Öffentlichkeitsrecht ist wieder die Zustimmung des jeweiligen Betreuers notwendig.
2.2 Nicht­funktionale Anforderungen
2.2.1 Internationalisierung
Gemäß der Aufgabenstellung aus Abschnitt 1.2 muss die Plattform mehrsprachig ausgelegt werden.
Das W3C führt eine Vielzahl von Aktivitäten durch, um Standards zu definieren, nach denen
internationalisierte Software modelliert und implementiert werden soll [i18nW3C].
Internationalisierung der Software bedeutet dabei, dass diese leicht (ohne den Quellcode ändern zu
müssen) an andere Sprachen und Kulturen angepasst werden kann. Internationalisierung wird im
englischsprachigen Raum oft mit i18n abgekürzt, wobei 18 für die ausgelassenen Buchstaben der
englischen Schreibweise steht (also 18 steht für „nternationalisatio“) im Wort „internationalisation“.
Eine gute Einführung in das Gebiet der Internationalisierung findet sich unter [i18nDb].
Der meist benutzte Ansatz um Übersetzungen und Sourcecode zu trennen funktioniert durch die
Verwendung von Identifiern im Sourcecode. Diese Identifier werden dann aus dem Sourcecodein
eigene Sprachdateien (eine Sprachdatei pro Sprache) extrahiert. Unterhalb eines jeden Identifiers
wird dann die Übersetzung notiert.
Dieses Modell soll auch bei der Implementierung der Bergsportplattform zur Anwendung kommen.
Übersetzer der Plattform kommen dadurch mit der Software nicht in Berührung und können sich auf
die Übersetzung der Sprachdateien konzentrieren.
2.2.2 Schutz des Dokumentationsmaterials
Gemäß der Aufgabenstellung in Abschnitt 1.2 muss das Dokumentationsmaterial urheberrechtlich
vor unerlaubter Vervielfältigung und unerlaubter Veröffentlichung geschützt werden. Aus diesem
Grund muss zuerst definiert werden, was überhaupt geschützt werden soll. Nachdem Fotos das
Herzstück der Bergsportplattform darstellen, müssen in erster Linie Fotos urheberrechtlich
geschützt werden. Da PDF­Dokumente das gesamte Dokumentationsmaterial beinhalten, müssen
speziell PDF­Dokumente vor unerlaubter Weitergabe geschützt werden.
Eine wichtige Frage ist weiters, was überhaupt unter Schutz zu verstehen ist. Weil man aus
technischer Sicht keine Person an der Weitergabe und der Veröffentlichung digitaler, aus dem
Internet bezogener Daten, hindern kann, ist unter dem Schutz des Dokumentationsmaterials
Walter Sunk 14

2 Anforderungsanalyse 30. August 2006
vielmehr die Möglichkeit zu verstehen, die rechtswidrig handelnde Person mit Hilfe des
weitergegebenen oder veröffentlichten Dokumentationsmaterials ausfindig zu machen. Kennt man
die Person, dann kann man rechtliche Schritte gegen diese einleiten. Aus diesem Grund wird der
Schutz des Dokumentationsmaterials wie folgt definiert:
Personen, die rechtswidrig handeln und Dokumentationsmaterial weitergeben oder veröffentlichen,
sollen bei Auffindung des Dokumentationsmaterials identifiziert werden können.
Es muss also das Dokumentationsmaterial Rückschlüsse auf die rechtswidrig handelnde Person
erlauben. Nachdem Personen anhand ihres Benutzernamens identifiziert werden, sollte also der
Benutzername in sämtliches Dokumentationsmaterial in verschiedenster Form eingebaut werden.
Schutz von Fotos
Fotos sollen durch nachfolgend beschriebene Methoden geschützt werden.
Beschreibung der Header­Tags:
Jedes digitale Bild besitzt Header Informationen, die beschrieben werden können. Diese Header­
Tags können nur von besseren Graphikprogrammen, nicht jedoch von einfachen
Graphikprogrammen manipuliert werden.
Annotierung:
Unter Annotierung versteht man, dass Text in das Bild integriert wird. Auf mittelgroßen Fotos und
auf Originalfotos sollen durch Annotierung Copyright­Vermerke und Benutzerdaten angebracht
werden. Auf Originalfotos sollen zusätzlich sensitive Benutzerdaten angebracht werden, sodass
Benutzer vor Weitergabe der Fotos aufgrund der sensitiven Daten abgeschreckt werden.
Wasserzeichen:
Auf jedem Foto soll ein Wasserzeichen angebracht werden. Als Wasserzeichen soll das Logo der
Bergsportplattform verwendet werden. Aufgrund des Wasserzeichens kann sofort festgestellt
werden, dass das Foto von der Bergsportplattform kommt. Wasserzeichen schützen somit
insbesondere vor der Veröffentlichung von Fotos im Internet (in Staaten, in denen das Urheberrecht
auch durchgesetzt werden kann). Das Wasserzeichen soll in einer solchen Größe angebracht
werden, dass es einen möglichst großen Teil des Fotos abdeckt ohne dabei aufdringlich zu werden.
Eine gute Einführung in den theoretischen Hintergrund zu Wasserzeichen bietet [DigWm99].
Steganographie:
Darunter versteht man das Verstecken eines Bildes in einem anderen Bild. Oft wird für den Begriff
„Steganographie“ auch der Begriff „Unsichtbare Wasserzeichen“ verwendet. Durch Steganographie
kann sehr effizient der Benutzer, der das Foto heruntergeladen hat, ausfindig gemacht werden. Um
diesen Schutz einzusetzen, wird zuerst ein kleines Bild mit dem Benutzernamen des Benutzers
erstellt. Dieses kleine Bild wird dann im gewünschten Foto versteckt. Wo das kleine Bild versteckt
ist, wird geheim gehalten. Ohne die geheim gehaltenen Zusatzinformation ist das kleine Bild im
Foto nicht auffindbar. Umgekehrt kann aber mit der geheim gehaltenen Information das kleine Bild
angezeigt und dadurch der Benutzer, der das Foto heruntergeladen hat, bestimmt werden.
Theoretische Grundlagen hierzu bietet u.a. [DigWm99].
Walter Sunk 15

2 Anforderungsanalyse 30. August 2006
Schutz von PDF­Dokumenten
PDF­Dokumente können vor unerlaubter Vervielfältigung durch ein Passwort geschützt werden.
Dieser Passwortschutz soll bei den PDF­Dokumenten von erworbenen Dokumentationen verwendet
werden. Als Passwort der PDF­Dokumente soll dabei nicht irgendein Passwort, sondern das Login­
Passwort des jeweiligen Benutzers verwendet werden. Ziel dieser Maßnahme ist es, den Benutzer
davor abzuhalten, das Passwort der PDF­Dokumente weiterzugeben. Würde ein Benutzer das
Passwort der PDF­Dokumente weitergeben, dann würde der Benutzer auch gleichzeitig sein Login­
Passwort weitergeben. Dadurch könnte der Annehmer des Passwortes den Benutzeraccount des
betreffenden Benutzers missbrauchen.
Aufgrund der Tatsache, dass das Login­Passwort gleich dem Passwort zum Öffnen der PDF­
Dokumente ist, darf das Login­Passwort auch nicht änderbar sein. Für den Fall, dass Benutzer ihr
Passwort vergessen, muss dieses also rekonstruierbar sein. Zu diesem Zweck erhalten Benutzer bei
der Registrierung einen Kontoschlüssel, mit dem das vergessene Passwort im Zuge einer
Passwortabfrage entschlüsselt und nachfolgend angezeigt werden kann.
Die PDF­Dokumente sollen außerdem sensitive Benutzerdaten enthalten, sodass Benutzer vor der
Weitergabe der PDF­Dokumente abgeschreckt werden. Gedruckte Fotos in PDF­Dokumenten
sollen aus Sicherheitsgründen ebenso annotiert werden wie die entsprechenden digitalen Fotos.
PDF­Dokumente werden überdies mit einem Admin­Passwort versehen. Mit diesem Admin­
Passwort kann das betreffende PDF­Dokument ebenfalls geöffnet werden. Dadurch wird erreicht,
dass ein Administrator ein weitergegebenes PDF­Dokument öffnen und den Weitergeber bestimmen
kann, um gegebenenfalls rechtliche Schritte gegen diesen einleiten zu können.
Allgemeines Schutzkonzept
Aus technischer Sicht ist zur Zeit kein 100%­Schutz des Dokumentationsmaterials möglich. Bei
Fotos können mit fortschrittlichen Graphikprogrammen Header­Tags manipuliert werden.
Annotierte Teile des Fotos können abgeschnitten werden. Gemäß [AttWm04] sind Angriffe auf
Wasserzeichen möglich. Im Falle der Steganographie kann der Ort eines im Foto versteckten
kleinen Bildes erraten und der betreffende Teil des Fotos ausgeschnitten werden. PDF­Dokumente
können mittels Passwort­Cracker angegriffen werden.
Ein Angreifer, der alle diese Angriffe durchführen möchte, braucht jedoch neben großem Know­
How auch mitunter viel Arbeitszeit. Die Sicherheitsmaßnahmen zum Schutz des
Dokumentationsmaterials zielen daher darauf ab, dass Angreifer aufgrund eines zu hohen Aufwands
erst gar keine Angriffe unternehmen. Als allgemeines Schutzkonzept wird daher der Ansatz
verfolgt, den Aufwand für mögliche Angriffe derart zu erhöhen, dass der Aufwand verglichen mit
dem Nutzen eines Angriffs zu hoch ist und aus diesem Grund von einem Angriff abgesehen wird.
Dieselbe Überlegung gilt auch für die Weitergabe von Dokumentationsmaterial. Damit ein Benutzer
von einer Weitergabe absieht, müssen der Aufwand und das Risiko, das Dokumentationsmaterial
weiterzugeben, wesentlich höher sein, als der Aufwand, das Dokumentationsmaterial zu erwerben.
Umgekehrt soll ein umfangreiches Online­Service nach dem Erwerb einer Dokumentation
bewirken, dass Benutzer Offline­Dokumentationsmaterial von dritten erst gar nicht annehmen, weil
sie auf das Online­Service nicht verzichten möchten.
2.2.3 Sicherheitsaspekte
In diesem Abschnitt werden die wichtigsten Sicherheitsaspekte der Bergsportplattform besprochen.
Walter Sunk 16

2 Anforderungsanalyse 30. August 2006
Log In System, Session Management, Aufladesystem
Das Log In System, das Session Management System und das Aufladesystem der
Bergsportplattform sollen vor Angriffen geschützt werden. Nachdem diese Bereiche gemäß der
Aufgabenstellung in Abschnitt 1.2 in das Praktikum [WaSu06] ausgegliedert wurden, sind
sämtliche Sicherheitsvorkehrungen in diesen Systemen Inhalt der Arbeit [WaSu06] und können dort
nachgelesen werden.
SSL Verschlüsselung
Auf der Bergsportplattform werden sensitive Benutzerdaten übertragen. Zu diesen Daten zählen
neben personenbezogenen Daten auch administrative Daten wie etwa Session Identifier. Wie in
Abschnitt 6.4 beschrieben müssen aus datenschutzrechtlichen Gründen personenbezogene Daten
und aus Gründen der Internet Security (gemäß [InetSec]) administrative Benutzerdaten geheim
gehalten werden. Deshalb sollen sensitive Daten zwischen Webserver und dem Browser des
Benutzers SSL­verschlüsselt übertragen werden.
Passwörter
Aus Gründen der Internet Security gemäß [InetSec] sollten Passwörter mindestens einen Groß­,
einen Kleinbuchstaben und eine Zahl beinhalten. Dies reduziert die Wahrscheinlichkeit drastisch,
dass durch Ausprobieren Passwörter gefunden werden. Aus diesem Grund sollen auf der Plattform
nur starke Passwörter zugelassen werden. Nachdem Benutzer oft dazu neigen, als einzige Zahl am
Ende des Passwortes eine 1 anzugeben, soll auch eine 1 am Ende des Passwortes verhindert werden.
Nachdem gemäß Abschnitt 2.2.2 Passwörter nicht geändert werden dürfen, kann in dem Fall, dass
der Benutzer sein Passwort vergisst, kein neues Passwort vergeben werden. Aufgrund dessen erhält
der Benutzer bei seiner Anmeldung einen Schlüssel, den sogenannten Kontoschlüssel, mit dem er
sein Passwort entschlüsseln kann. Um zu verhindern, dass im Falle eines Einbruchs alle
Kontoschlüssel gestohlen werden könnten und somit sämtliche Passwörter in Gefahr wären, werden
Kontoschlüssel nicht am Server aufbewahrt. Damit nun der Benutzer sein Passwort auch
entschlüsseln kann, wird es mit dem Kontoschlüssel verschlüsselt am Server aufbewahrt.
Um ein Login mit Benutzername und Passwort zu verifizieren, muss das Passwort des Benutzers
geprüft werden. Um das Passwort gleichzeitig vor Einbrüchen am Server zu schützen, wird es am
Server einweg­verschlüsselt gespeichert (eine Entschlüsselung ist also nicht möglich). Dazu soll ein
Hashverfahren zur Anwendung kommen. Zur Überprüfung des Passwortes beim Login muss dann
das eingegebene Passwort ebenfalls einweg­verschlüsselt und mit dem einweg­verschlüsselten
gespeicherten Passwort verglichen werden.
Auf der Bergsportplattform wird also ein Passwort in folgenden 2 Formen gespeichert:
• zweiweg­verschlüsselt zur Passwortabfrage, wobei der Schlüssel zum Entschlüsseln (der
sogenannte Kontoschlüssel) beim Benutzer liegt
• einweg­verschlüsselt zur Überprüfung des Passwortes beim Login
Cachen von Fotos am Browser des Benutzers
Nachdem von der Bergsportplattform umfangreiche Originalfotos heruntergeladen werden können,
kann es zu Engpässen der zur Verfügung stehenden Bandbreite kommen. Um dies bestmöglich zu
verhindern, sollen Fotos nicht immer neu vom Server geladen, sondern im Cache des Browsers des
jeweiligen Benutzers gespeichert werden. Es sind geeignete Maßnahmen zu treffen, dass der
Walter Sunk 17

2 Anforderungsanalyse 30. August 2006
jeweilige Browser die betreffenden Fotos auch tatsächlich in seinem Cache aufnimmt. Umgekehrt
muss aber auch sichergestellt werden, dass Fotos nach Änderungen am Server wieder neu und nicht
vom Cache geladen werden, damit der Benutzer die Änderungen mitbekommt. Daher soll von
jedem Foto die Zeit der letzten Änderung gespeichert werden. Dadurch kann dem Browser des
Benutzers mitgeteilt werden, ob das Foto neu geladen werden muss oder ob es aus dem Cache
geladen werden kann.
User­Interface zur Administration
Die gesamte Internetseite soll online per User­Interface administrierbar sein. Nachdem dies jedoch
ein großes Sicherheitsrisiko darstellt (für den Fall dass ein Angreifer das Passwort eines
Administrators herausfindet), soll die Administration nur bei Bekanntgabe der IP­Adresse des
jeweiligen Administrators möglich sein. Ein jeder Administrator, der die Internetseite online über
das User­Interface administrieren möchte, muss also zuerst im System seine IP­Adresse bekannt
geben. Zu diesem Zweck muss sich der jeweilige Administrator zuerst über eine SSH­Verbindung
einloggen und seine IP­Adresse im System eintragen. Eine Online­Administration ist somit nur für
die Zeit eines gültigen IP­Adresseintrags möglich. Aus Sicherheitsgründen muss daher nach jeder
Administration die eingetragene IP­Adresse wieder aus dem System entfernt werden.
Walter Sunk 18

3 Modellierung 30. August 2006
3 Modellierung
In diesem Kapitel wird die Modellierung der Bergsportplattform aufbauend auf die Use Cases aus
Kapitel 2 gezeigt. Viele in Kapitel 2 beschriebene Use Cases können direkt implementiert werden,
manche Use Cases müssen jedoch genauer modelliert werden. Dies erfolgt in Abschnitt 3.1. Im
Anschluss daran wird die für die Plattform notwendige Klassenmodellierung in Abschnitt 3.2
vorgenommen. Aufbauend auf der Klassenmodellierung und den Use Cases aus Kapitel 2 wird die
Modellierung der einzelnen Softwarepakete in Abschnitt 3.3 besprochen. Die Modellierung soll
eine vollständige Implementierung der Bergsportplattform ermöglichen und ist daher auch
Schwerpunkt der vorliegenden Arbeit.
3.1 Modellierung ausgewählter Use Cases
Im folgenden Abschnitt werden wichtige Use Cases aus Kapitel 2 besprochen, deren Abläufe einer
genaueren Modellierung bedürfen.
3.1.1 Tourenmenü
Das Subsystem Tourenmenü der Startseite (siehe Abschnitt 2.1.1) bietet die Möglichkeiten, Touren
und Alben auszuwählen oder zu suchen. Dementsprechend müssen die Use Cases Tourenauswahl,
Albenauswahl und Suche genauer modelliert werden. Die zugehörigen Aktivitätsdiagramme zeigt
Abbildung 3.1.1. Beim Auffinden von Touren und Alben werden folgende 3 Strategien verfolgt:
Abbildung 3.1.1: Modellierung der Use Cases im Tourenmenü
1) Der Benutzer möchte sich einen Überblick verschaffen, welche Touren es in einem
bestimmten Gebiet überhaupt gibt. Eine Gebietsauswahl (nach Gebirgen hierarchisch
geordnet) soll das Auffinden von Touren im gewünschten Gebiet ermöglichen. In diesem Fall
kommt der Use Case Tourenauswahl zur Anwendung.
Walter Sunk 19

3 Modellierung 30. August 2006
2) Der Benutzer möchte sich einen Überblick verschaffen, in welchen Gebieten mehrere Touren
eines bestimmten Typs (z.B. Wanderungen) dokumentiert sind, um z.B. eine ganze Woche
Bergurlaub zu planen. Eine Albenauswahl soll dem Benutzer Tourenalben zeigen, die
derartige ausgewählte Touren beinhalten. In diesem Fall kommt der Use Case Albenauswahl
zur Anwendung.
3) Der Benutzer möchte Touren und Tourenalben mit Hilfe von Schlüsselwörtern suchen. Z.B.
weiß der Benutzer genau, welche Tour mit welchem Ziel (z.B. ein Gipfel, eine Hütte oder ein
See) er unternehmen möchte. Eine direkte Suche soll zur Anwendung kommen, in der der
Benutzer nach Touren und Tourenalben durch Eingabe von Schlüsselwörtern suchen kann. In
diesem Fall kommt der Use Case Suche zur Anwendung.
Tourenauswahl
Im ersten Fall ist eine 3­stufige Gliederung nach Gebirgsregion, Gebirge und Gebirgsgruppe
sinnvoll, weil diese auf die meisten alpinen Ziele zutrifft. So befindet sich beispielsweise der
Großglockner (der höchste Berg Österreichs) in den Ostalpen (Gebirgsregion), dort in den Hohen
Tauern (Gebirge), und dort in der Glocknergruppe (Gebirgsgruppe).
Ziele von Wanderungen müssen nicht immer Gipfel sein, oft ist auch ein See oder eine Hütte ein
schönes Ziel für einen Tagesausflug. Deshalb erfolgt innerhalb der Gebirgsgruppe eine Zielauswahl,
die dem Benutzer sämtliche dokumentierte Ziele in dieser Gebirgsgruppe zeigt. Eine Tour kann
auch mehrere Ziele beinhalten. Nachdem der Benutzer ein Ziel ausgewählt hat, werden ihm alle
Touren angezeigt, die dieses Ziel beinhalten. Die Anzeige einer Tour besteht aus einer Menge von
Unteraktivitäten und wird in Abschnitt 3.1.2 genauer beschrieben.
Albenauswahl
Bei der Albenauswahl wählt der Benutzer zuerst einen Albumtyp aus (z.B. ein Wanderalbum oder
ein Hochtourenalbum). Danach werden ihm alle Tourenalben dieses Typs angezeigt. Die Anzeige
eines einzelnen Albums wird in Abschnitt 3.1.3 genauer beschrieben. Jedes Tourenalbum beinhaltet
ausgewählte Touren, die wiederum einzeln angezeigt werden können.
Suche
In einer Suche werden entweder Touren oder Alben gefunden. Werden Touren gefunden, dann wird
eine Tourenauswahl mit den gefundenen Touren angezeigt, Gleiches gilt für Alben. Werden keine
Touren und Alben gefunden, so wird der Benutzer informiert und kann eine neue Suche mit anderen
Schlüsselwörtern beginnen.
3.1.2 Tour anzeigen
Die Aktivität Tour anzeigen ist Inhalt der Use Cases des Subsystems Tourenmenü der Startseite
(siehe Abschnitt 2.1.1) Sie wird auch in Abschnitt 3.1.1 zur Modellierung der Use Cases des
Tourenmenüs verwendet. Diese Aktivität besteht intern aus einer Menge von weiteren Aktivitäten,
wobei alle Aktivitäten gemeinsam das gesamte Dokumentationsmaterial einer Tour zeigen.
Abbildung 3.1.2 zeigt den Aufbau. Auf der Internetseite sollen die Aktivitäten durch Links
verbunden werden. Daher besitzen die Kannten die Namen der Links.
Das Dokumentationsmaterial einer Tour besteht dabei aus folgenden Teilen:
Walter Sunk 20

3 Modellierung 30. August 2006
Abbildung 3.1.2: Aktivität Tour anzeigen
• den Übersichtsdaten (Name, Tourenziele, Stützpunkte, Höhe, Länge, Zeit, etc.)
• dem Beschreibungs­PDF und dem Foto­PDF
• dem Fotomenü
• der Beschreibung der Tour
• Informationen über den Autor
Eine jede Tour kann auch in Form von 2 PDF­Dokumenten bezogen werden. Ein PDF­Dokument
enthält dabei sämtliche textliche Daten der Tour (das Beschreibungs­PDF) und das andere PDF­
Dokument (das Foto­PDF) enthält alle Fotos der Tour (1 Foto pro Seite).
Über das Fotomenü gelangt der Benutzer zum gesamten Foto­ und Kartenmaterial der Tour. Das
Fotomenü besteht daher intern aus folgenden Teilen:
Walter Sunk 21

3 Modellierung 30. August 2006
• aus der Fotogalerie: In dieser werden alle Fotos der Tour in einem kleinen Format angezeigt.
• aus den Einzelfotos: In diesem Teil wird ein Foto pro Webseite angepasst auf die Größe der
Webseite angezeigt. Die Einzelfotos sind dabei untereinander verlinkt. Ein Link in einem Foto
bedeutet dabei, dass das verlinkte Foto an der Stelle des Links aufgenommen wurde.
• aus den Originalfotos: In diesem Teil wird ein Originalfoto pro Webseite angezeigt. Die
Auswahl des Originalfotos erfolgt dabei durch einen Klick auf ein Thumbnail. Jedes
Originalfoto kann heruntergeladen werden.
• aus den Karten zur Tour: Hier können die Karten der Tour online eingesehen und auch
heruntergeladen werden. Die Karten sind dabei mit den vorhandenen Fotos verlinkt. Ein Link
in einer Karte bedeutet, dass das verlinkte Foto an der Stelle des Links aufgenommen wurde.
Dadurch kann der Benutzer auf der Karte durch die Tour virtuell durchgehen.
Die Beschreibung einer Tour setzt sich intern aus folgenden Teilen zusammen (diese Teile sollen
alle auf der gleichen Internetseite angezeigt werden):
• aus der Anreise und der Zufahrt: Unter der Anreise versteht man die Reise bis zum
nächstgelegenen Ort der Tour. Unter der Zufahrt versteht man die Fahrt vom nächstgelegenen
Ort bis zum Ausgangspunkt der Tour. Dieser Teil der Beschreibung ist sachlich verfasst.
• aus dem Tourenverlauf: Der Tourenverlauf beschreibt den gesamten Weg der Tour. In den
Tourenverlauf können Links zu den Fotos eingebaut werden. Der Benutzer kann dadurch
anhand des Tourenverlaufs durch die Tour virtuell durchgehen. Der Tourenverlauf ist ebenfalls
sachlich verfasst.
• aus den Erlebnissen und Eindrücken: Hier kann der Autor über seine Erlebnisse während der
Tour und über seine Eindrücke von der Tour erzählen. Die Erlebnisse und Eindrücke können
subjektiv und persönlich verfasst sein.
3.1.3 Album anzeigen
Die Aktivität Album anzeigen ist ebenfalls Inhalt der Use Cases des Subsystems Tourenmenü der
Startseite (siehe Abschnitt 2.1.1). Sie wird auch in Abschnitt 3.1.1 zur Modellierung der Use Cases
des Tourenmenüs verwendet. Diese Aktivität besteht intern wieder aus einer Menge von weiteren
Aktivitäten, wobei alle Aktivitäten gemeinsam das gesamte Dokumentationsmaterial des Albums
zeigen. Abbildung 3.1.3 zeigt den Aufbau. Auf der Internetseite sollen die Aktivitäten durch Links
verbunden werden. Daher besitzen die Kannten die Namen der Links.
Das Dokumentationsmaterial eines Tourenalbums besteht aus folgenden Teilen:
• aus den Übersichtsdaten: Die Übersichtsdaten bestehen aus dem Namen und einer (kurzen)
Beschreibung des Albums, einem Vorwort zum Album, aus Impressionsfotos und aus einer
Liste, welche die Touren des Albums auflistet. Die Übersichtsdaten des Albums werden alle
auf einer gemeinsamen Seite angezeigt.
• aus den Touren zum Album: Eine jede Tour besteht dabei aus den einzelnen Teilen wie in
Abschnitt 3.1.2 beschrieben.
Möchte ein Benutzer eine Tour eines Albums einsehen (genauer: der Benutzer führt einen Link aus,
der die Tour zum entsprechenden Album laden soll), dann muss zuerst geprüft werden, ob die Tour
überhaupt zum Album gehört. Ist dies der Fall, so kann die Tour angezeigt werden, andernfalls
bedarf es einer Fehlermeldung. Diese Überprüfung ist insbesondere dann wichtig, wenn ein
Walter Sunk 22

3 Modellierung 30. August 2006
Benutzer ein Album erworben hat und eine Tour anfordert. Diese Tour muss dann zum Album
gehören, andernfalls ist der Benutzer nicht berechtigt, die Tour zu beziehen.
Abbildung 3.1.3: Aktivität Album anzeigen
3.1.4 Dokumentation kaufen
Gemäß Abschnitt 2.1.2 muss der Use Case Doku kaufen genauer beschrieben werden. Dieser
abstrahiert die Use Cases Tour kaufen und Album kaufen. Nachdem der Kaufvorgang für eine Tour
und für ein Album im wesentlichen derselbe ist, werden gemäß Abschnitt 2.1.2 beide Use Cases
gleich behandelt und können durch den einzigen Use Case Doku kaufen beschrieben werden. Zu
diesem Zweck wird für Tour und für Album das Wort „Doku“ (für Dokumentation) verwendet.
Das zugehörige Aktivitätsdiagramm zeigt Abbildung 3.1.4. Ein Benutzer der Internetseite lässt sich
eine Doku anzeigen. Bei Dokus, die käuflich erworben werden, sind nur die Übersichtsdaten frei
zugänglich. In den Übersichtsdaten befindet sich ein Link, um die Doku zu kaufen. Nach
Ausführung dieses Links ist das weitere Verfahren davon abhängig, ob der Benutzer bereits
eingeloggt ist, d.h. eine Session vorhanden ist, oder nicht.
Um gekaufte Dokus mit ihren Käufern in Beziehung zu stellen, ist es notwendig, dass sich Benutzer
vor dem Kauf einer Dokumentation auf der Bergsportplattform anmelden. Eine Doku kann also nur
dann gekauft werden, wenn sich der Benutzer eingeloggt hat und eine Session (bzw. eine Session­
ID) des Benutzers vorhanden ist.
Für den Fall, dass der Benutzer nicht eingeloggt ist, wird er zum Login weitergeleitet und
aufgefordert, sich einzuloggen. Neue Benutzer haben noch keine Login­Daten (Benutzername und
Passwort). Daher wird neuen Benutzern angeboten, sich auf der Bergsportplattform anzumelden.
Nach der Anmeldung werden die Benutzer zum Login weitergeleitet. Ist das Login erfolgreich, so
wird der Benutzer wieder zur Doku zurückgeleitet.
Gemäß der Aufgabenstellung in Abschnitt 1.2 muss aufgrund geringerer Überweisungsspesen
zuerst ein Guthaben aufgeladen werden, danach kann der Kunde dann Dokumentationen erwerben.
Für den Fall, dass der Benutzer bereits eingeloggt ist (es existiert in diesem Fall eine zugehörige
Session), muss also zuerst geprüft werden, ob das Guthaben des Kunden ausreicht, die Doku zu
kaufen. Ist das Guthaben ausreichend, dann kann der Kauf durchgeführt werden. Andernfalls muss
das Guthaben aufgeladen werden. Die Aufladung des Guthabens ist selbst wieder ein komplexer
Prozess, wurde gemäß der Aufgabenstellung in Abschnitt 1.2 aus dieser Arbeit ausgegliedert und
Walter Sunk 23

3 Modellierung 30. August 2006
kann in [WaSu06] nachgelesen werden.
Abbildung 3.1.4: Modellierung des Use Case Doku kaufen
Wenn noch nicht alle Voraussetzungen für dem Kauf erfüllt sind, dann ist es im Kaufprozess
wichtig, dass der Benutzer immer wieder zur Doku zurückgeleitet wird. Ansonsten müsste er die
gewünschte Doku immer neu suchen, wodurch man einen Benutzer verärgern könnte.
3.1.5 Login
Der Use Case Login ist Inhalt der Use Cases des Subsystems Login der Startseite (siehe Abschnitt
2.1.1). Er wird nun im Hinblick auf die Funktionalität genauer beschrieben. Die technische
Realisierung und die notwendigen Sicherheitsmaßnahmen beim Login sind nicht Gegenstand dieser
Arbeit. Diese werden in [WaSu06] beschrieben. Daher beschränkt sich die Beschreibung in dieser
Arbeit lediglich auf die Funktionalität, die in Abbildung 3.1.5 dargestellt ist.
Ein Benutzer kann durch 2 Möglichkeiten zum Login gelangen. Entweder er klickt auf einen Link
„Einloggen“ oder er ruft eine Mitgliederseite auf, die nur für eingeloggte Benutzer zugänglich ist. In
letzterem Fall wird der Benutzer zum Login weitergeleitet. Hat der Benutzer noch keine Login­
Daten (Benutzername und Passwort), dann muss er sich zuerst auf der Bergsportplattform
anmelden. Nicht erfolgreiche Logins führen dazu, dass der Benutzer erneut seine Login­Daten
eingeben muss (wie in [WaSu06] beschrieben hat der Benutzer aus Sicherheitsgründen innerhalb
Walter Sunk 24

3 Modellierung 30. August 2006
eines bestimmten Zeitraums nur eine bestimmte Anzahl an Login­Versuchen).
Abbildung 3.1.5: Modellierung der Funktionalität des Use Case Login
Nach einem erfolgreichen Login sollte aus Gründen der Benutzerfreundlichkeit wie folgt
vorgegangen werden:
• Falls der Benutzer über einen Link „Einloggen“ gekommen ist, dann sollte ihm der Referer,
also ein Link auf die zuletzt besuchte Seite angeboten werden.
• Falls der Benutzer über den Aufruf einer Mitgliederseite gekommen ist, dann sollte der
Benutzer auch wieder zu dieser Mitgliederseite zurückgeleitet werden.
In beiden Fällen sollen die entsprechenden Vorgehensweisen nach einem erfolgreichen Login auch
dann durchgeführt werden, wenn der Benutzer zuvor eine Anmeldung durchgeführt hat und / oder
Loginversuche des Benutzers fehlgeschlagen sind.
3.1.6 Anmelden
Der Use Case Anmelden ist Inhalt der Use Cases des Subsystems Login der Startseite (siehe
Abschnitt 2.1.1). Dieser wird nun genauer behandelt. Wie bereits in Abschnitt 3.1.4 besprochen ist
es für den Kauf von Dokumentationen notwendig, dass sich Benutzer auf der Plattform anmelden.
Die Anmeldung verläuft dabei in 2 Stufen. In der ersten Stufe werden die Daten des Benutzers
entgegengenommen. Danach wird dem Benutzer eine E­Mail mit einem Aktivierungslink geschickt.
Nach Ausführung dieses Links wird dann in der zweiten Stufe ein neuer Account für den Benutzer
eingerichtet. Wie die beiden Stufen im Detail verlaufen, zeigen die Abbildungen 3.1.6 und 3.1.7.
In beiden Stufen wird angenommen, dass das Format aller Benutzereingaben vor dem Eintrag in die
Datenbank geprüft wird, um sogenannte Code­Injections zu vermeiden. Wie in [WaSu06]
beschrieben, müssen derartige Code­Injections unbedingt vermieden werden, weil dadurch
Angreifer die Datenbank manipulieren können. Wie derartige Prüfungen effizient durchgeführt
Walter Sunk 25

3 Modellierung 30. August 2006
werden können, wird ebenfalls in [WaSu06] diskutiert.
Abbildung 3.1.6: Modellierung der ersten Stufe der Anmeldung
Die Anmeldung wird durch ein sogenanntes „Captcha“ vor automatischen Anmeldungen durch
Maschinen geschützt. Wie auf [CMU] beschrieben, ist ein Captcha ein Test, der in der Regel nur
von Menschen, nicht aber von Maschinen lösbar ist. Derartige Tests werden z.B. durch
Walter Sunk 26

3 Modellierung 30. August 2006
Interpretieren einer Zeichenkette in einem Bild durchgeführt. Wie ein Captcha genau funktioniert
und wie es auf der Bergsportplattform Anwendung findet, kann in [WaSu06] nachgelesen werden
und ist nicht Thema dieser Arbeit.
In der ersten Stufe (dargestellt in Abbildung 3.1.6) schickt der Benutzer einen Request zum
Anmelden (register) an den Server. Der Server startet daraufhin eine neue Registrierung und fordert
den Benutzer auf, Benutzername und Passwort einzugeben. Sollte der Benutzername bereits
vorhanden sein, muss ein anderer Benutzername gewählt werden. Diese Überprüfung läuft in einer
Schleife ab, solange bis ein nicht existierender Benutzername eingeben wurde. Ist der
Benutzername gültig, dann wird die Registrierung mit diesem upgedatet.
Danach wird der Benutzer aufgefordert, seine E­Mail Adresse einzugeben. Die E­Mail Adresse
muss im System ebenfalls eindeutig sein, um Neuigkeiten über die Internetseite eindeutig an
Benutzer zusenden zu können. Gibt der Benutzer eine E­Mail Adresse ein, die bereits in
Verwendung ist, dann muss er eine andere zur Verfügung stellen.
Danach werden die Profildaten des Benutzers aufgenommen, das sind Anrede*, Titel, Vor­* und
Nachname*, Geburtsdatum*, Anschrift*, PLZ*, Wohnort*, Staat*, Handy­Nummer,
Telefonnummer, Homepage, wobei die mit * gekennzeichneten Angaben für den Benutzer
verpflichtend sind. Nachdem das Profil aufgenommen wurde, wird die Registrierung mit den
Profildaten upgedatet und der Benutzer erhält eine E­Mail mit einem Aktivierungslink. Der
Benutzer muss diesen Link ausführen, um zur zweiten Stufe zu gelangen. Dieses Vorgehen ist
notwendig, damit die E­Mail Adresse des Benutzers verifiziert werden kann. Sollte ein Benutzer
eine ungültige E­Mail Adresse angeben, dann erhält er auch nicht den Aktivierungslink und kann
somit keinen neuen Benutzeraccount eröffnen.
Nachdem der Benutzer den Aktivierungslink in der E­Mail Adresse ausgeführt hat, gelangt er zur
zweiten Stufe der Registrierung, dargestellt in Abbildung 3.1.7. In dieser Stufe wird der
Benutzeraccount des Kunden im Falle eines gültigen Aktivierungslinks eröffnet.
Der Aktivierungslink muss einen Registrierungsidentifyer (eine RegID) beinhalten, mit dem die
zugehörige Registrierung identifiziert werden kann. Durch Ausführung des Aktivierungslinks wird
also die RegID übertragen. Danach wird in der Datenbank nachgesehen, ob eine Registrierung mit
dieser RegID existiert. Ist dies nicht der Fall, so wird der Vorgang abgebrochen und der Benutzer
erhält eine Fehlermeldung. Aus Administrationsgründen hat jede Registrierung eine Ablaufzeit (ein
Feld ExpireTime), d.h. eine Registrierung muss innerhalb einer bestimmten Zeit abgeschlossen sein.
Dies dient dazu, dass angefangene Registrierungen, zu denen kein Aktivierungslink gesendet wurde,
nach der Ablaufzeit aus der Datenbank gelöscht werden können. Ist die Registrierung noch nicht
abgelaufen, kann eine neuer Benutzeraccount eingerichtet werden.
Gemäß Abschnitt 2.2.3 wird das Passwort des Benutzers aus Sicherheitsgründen in der Datenbank
zweifach wie folgt gespeichert. Zum einen als Hash und zum zweiten Mal mit einem Schlüssel
verschlüsselt, der beim Benutzer (nicht jedoch auf der Plattform) aufbewahrt wird. Der Schlüssel
zum Entschlüsseln des Passwortes wird Kontoschlüssel (AccountKey) genannt und dem Benutzer
nach einer erfolgreichen Anmeldung per E­Mail zugeschickt. Zu diesem Zweck müssen nun das
Hash­Passwort und der Kontoschlüssel generiert und das Passwort mit dem Kontoschlüssel
verschlüsselt werden. Dazu kommt ein Crypter­Modul zum Einsatz.
Die Registrierungsdaten, das Hash­Passwort und das verschlüsselte Passwort werden nun in Form
eines neuen Benutzeraccounts in der Datenbank gespeichert. Danach wird dem Benutzer eine E­
Mail geschickt, in der sich wichtige Informationen zu seinem Benutzeraccount befinden. Unter
Walter Sunk 27

3 Modellierung 30. August 2006
diesen Informationen befinden sich der Benutzername und der Kontoschlüssel zum Entschlüsseln
des Passwortes, für den Fall, dass der Benutzer sein Passwort vergessen sollte. Die erfolgreiche
Einrichtung des Benutzeraccounts wird dem Benutzer mitgeteilt und er wird über die Zusendung
der E­Mail mit den Accountdaten informiert.
Abbildung 3.1.7: Modellierung der zweiten Stufe der Anmeldung
3.1.7 Passwortabfrage
Der Use Case Passwortabfrage ist Inhalt der Use Cases des Subsystems Login der Startseite (siehe
Abschnitt 2.1.1). Er und wird nun im Detail diskutiert. Sollte ein Benutzer sein Passwort zum Login
vergessen haben, dann kann er, wie in Abschnitt 2.2.3 erklärt, sein Passwort mit Hilfe seines
Kontoschlüssels entschlüsseln. Es wird davon ausgegangen, dass der Benutzer den Kontoschlüssel
bei der Registrierung in der E­Mail mit seinen Accountdaten gemäß Abschnitt 3.1.6 erhalten hat.
Walter Sunk 28

3 Modellierung 30. August 2006
Angriffsmöglichkeiten
Im wesentlichen läuft die Passwortabfrage wie folgt ab (die Details folgen später in diesem
Abschnitt). Um den Benutzer zu identifizieren, muss dieser zu Beginn der Passwortabfrage seine E­
Mail Adresse eingeben. Danach wird an diese Adresse eine E­Mail mit einem Abfragelink
geschickt, der einen Request­Identifyer, kurz eine RequestID, beinhaltet. Der Benutzer muss nun
diesen Abfragelink ausführen. Nach Ausführung des Abfragelinks kann der Benutzer durch die
RequestID identifiziert werden. Der Benutzer gelangt dann zur Eingabe des Kontoschlüssels, mit
dessen Hilfe dann das Passwort entschlüsselt wird. Dadurch ergeben sich folgende Möglichkeiten,
die Passwortabfrage zu manipulieren, anzugreifen oder auszunützen.
1) Nachdem die Passwortabfrage öffentlich zugänglich ist, könnte ein Angreifer versuchen,
beliebig viele E­Mail Adressen anzugeben. Dadurch kann ein Angreifer herausfinden, welche
E­Mail Adressen in der Datenbank vorhanden sind.
2) Nachdem nach der Eingabe einer in der Datenbank vorhandenen E­Mail Adresse eine E­Mail
an diese Adresse gesendet wird, könnte ein Angreifer, der die E­Mail Adresse eines Benutzers
kennt, beliebig viele E­Mails an einen Benutzer schicken. Das wäre nicht nur für den Benutzer
sehr störend, sondern auch aus rechtlichen Gründen für die Plattform gefährlich.
3) Nachdem E­Mails immer Plain­Text und in der Regel unverschlüsselt übertragen werden,
kann ein Angreifer versuchen, den Abfragelink mit der RequestID abzuhören (zu „sniffen“)
und könnte dadurch zur Eingabe des Kontoschlüssels gelangen.
4) Ein Angreifer, der es bis zur Eingabe des Kontoschlüssels geschafft hat, könnte beliebig viele
verschiedene Kontoschlüssel ausprobieren, um das Passwort des Benutzers zu entschlüsseln.
Alle diese 4 Möglichkeiten des Angriffs der Passwortabfrage werden wie nachfolgend beschrieben
verhindert:
1) Um zu verhindern, dass beliebig viele E­Mail Adressen ausprobiert werden können, wurde in
der Arbeit [WaSu06] ein BruteForceRequest­Modul entworfen. Dieses Modul prüft, ob ein
bestimmter Benutzer probiert. Ist dies der Fall, so meldet das Modul eine Brute Force Attacke,
woraufhin die Passwortabfrage abgebrochen wird.
2) Um zu verhindern, dass dieselbe E­Mail Adresse immer wieder neu eingegeben wird, werden
Requests mit derselben E­Mail Adresse innerhalb eines Zeitfensters (dem
REQUEST_WINDOW) gezählt. Sind zu viele Requests vorhanden, wird die Passwortabfrage
abgebrochen.
3) Um zu verhindern, dass ein Angreifer einen abgehörten Abfragelink verwenden kann, wird IP­
Checking verwendet. Darunter wird verstanden, dass die IP­Adresse des Benutzers
aufgezeichnet wird. Nachdem ein Angreifer in der Regel auf einer anderen Maschine sitzt, hat
er in der Regel auch eine andere IP Adresse. Sollte also ein Request mit einer unerwarteten IP­
Adresse auftreten, dann wird die Passwortabfrage abgebrochen. Es könnte sein, dass der
Angreifer dennoch dieselbe IP­Adresse hat oder in der Lage ist, die IP­Adresse zu
manipulieren. Es wird jedoch davon ausgegangen, dass dies sehr selten der Fall ist. Es besteht
also ein gewisses Restrisiko, das aufgrund einer klein geschätzten Wahrscheinlichkeit in Kauf
genommen wird.
4) Um zu verhindern, dass beliebig viele Kontoschlüssel zum Entschlüsseln des Passwortes
ausprobiert werden, werden die Entschlüsselungsversuche gezählt. Es werden nur eine
Walter Sunk 29

3 Modellierung 30. August 2006
bestimmte Anzahl an Versuchen zugelassen, danach wird die Passwortabfrage abgebrochen.
5) Im weiteren ist die Passwortabfrage durch ein Timeout geschützt. Das Passwort muss also
innerhalb einer bestimmten Zeit abgefragt werden. Die Zeit für einen möglichen Angriff ist
dadurch beschränkt. Außerdem erleichtert die Verwendung eines Timeouts die Administration,
weil dadurch abgelaufene Passwortabfragen aus der Datenbank gelöscht werden können.
Klassenmodellierung
Um die besprochenen Sicherheitsmaßnahmen zu modellieren, wird eine Passwortabfrage durch die
Klasse PwRequest beschrieben und in der Datenbank aufgezeichnet. Abbildung 3.1.8 zeigt das
zugehörige Klassendiagramm.
Abbildung 3.1.8: Klassendiagramm zur Passwortabfrage
Um Angriff 2) zu verhindern, werden wie besprochen die maximal ausführbaren Requests bezüglich
einer E­Mail Adresse (MAX_REQUESTS_PER_EMAIL) innerhalb eines vorgegebenen
Zeitfensters (REQUEST_WINDOW) definiert. Um Angriff 3) zu verhindern, wird wie beschrieben
IP­Checking verwendet. Dazu wird die IP­Adresse des zugehörigen Benutzers aufgezeichnet. Um
Angriff 4) zu verhindern, müssen die Entschlüsselungsversuche gezählt werden. Dazu wird das Feld
Tries verwendet und die maximal möglichen Versuche werden definiert
(MAX_DECRYPT_TRIES). Um die Passwortabfrage zeitlich zu begrenzen, wird wie besprochen
ein Timeout definiert (REQUEST_TIMEOUT). Mit Hilfe dieses Timeouts kann die Ablaufzeit
(ExpireTime) der Passwortabfrage zu ExpireTime = RequestTime + REQUEST_TIMEOUT
berechnet werden, wobei die RequestTime der Zeitpunkt des Starts der Passwortabfrage ist. Wie
bereits eingangs in diesem Kapitel besprochen, wird der Benutzer anhand der RequestID
identifiziert. Zur Aufzeichnung der RequestID dient das Feld RequestID. Aus Sicherheitsgründen
wird zu jeder Passwortabfrage auch noch die E­Mail Adresse gespeichert, um feststellen zu können,
ob sich manche E­Mail Adressen ungewöhnlich verhalten.
Jede Passwortabfrage wird also in der Datenbank in einer Tabelle gespeichert. Dazu muss ein
Schlüssel definiert werden. Als Schlüssel kann die RequestID dienen. Sollte es möglich sein, dass
diese nicht eindeutig ist, dann kann als Schlüssel auch eine Kombination aus den Feldern Email und
/ oder RequestTime und / oder RequestID verwendet werden.
Die Klasse PwRequestHandler dient dazu, Instanzen der Klasse PwRequest in der Datenbank zu
administrieren. Die Namen der Methoden sollten selbsterklärend sein. Zu beachten ist, dass die
Methode getRequestsPerEmail() die Anzahl der Passwortabfragen zu einer E­Mail Adresse
innerhalb eines bestimmten Zeitfensters zurückliefert. Dadurch kann Angriff 2) verhindert werden.
Walter Sunk 30

3 Modellierung 30. August 2006
Dynamische Modellierung
Wie die Passwortabfrage nun im Detail gemäß den besprochenen Sicherheitsüberlegungen
durchgeführt wird, zeigen die Abbildungen 3.1.9 und 3.1.10. Die Passwortabfrage wird dabei in
zwei Stufen durchgeführt. In der ersten Stufe (Abbildung 3.1.9) wird der Abfragelink an den
Benutzer geschickt, in der zweiten Stufe (Abbildung 3.1.10) wird das Passwort des Benutzers mit
Abbildung 3.1.9: Sequenzdiagramm zur Modellierung der ersten Stufe der Passwortabfrage
Hilfe des Kontoschlüssels entschlüsselt.
Walter Sunk 31

3 Modellierung 30. August 2006
Abbildung 3.1.10: Sequenzdiagramm zur Modellierung der zweiten Stufe der Passwortabfrage
Walter Sunk 32

3 Modellierung 30. August 2006
In der ersten Stufe (Abbildung 3.1.9) fordert der Benutzer eine Passwortabfrage an und wird
daraufhin aufgefordert, seine E­Mail Adresse bekannt zu geben. Danach wird mit dem in [WaSu06]
entwickelten BruteForceRequest­Modul geprüft, ob eine Brute Force Attacke vorliegt. Ist dies der
Fall, wird der Benutzer darüber informiert und die Passwortabfrage wird gestoppt. Danach wird
geprüft, ob die angegebene E­Mail Adresse in der Datenbank in einem Benutzeraccount vorkommt.
Ist dies nicht der Fall, erfolgt ein Abbruch der Passwortabfrage. Ist die E­Mail Adresse gültig, wird
nachfolgend geprüft, ob der Benutzer bereits mehrere Passwortabfragen mit derselben E­Mail
Adresse innerhalb eines vorgegebenen Zeitfensters begonnen hat. Wird eine bestimmte Anzahl an
begonnenen Passwortabfragen überschritten, so muss die vorliegende Passwortabfrage gemäß den
vorigen Sicherheitsüberlegungen abgebrochen werden. Nachdem alle Prüfungen positiv absolviert
wurden, wird eine neue Passwortabfrage gestartet, eine E­Mail mit dem Abfragelink wird an die E­
Mail Adresse des Benutzers geschickt und der Benutzer wird über die gesendete E­Mail informiert.
Mit dem Ausführen des Abfragelinks in der E­Mail Adresse beginnt die zweite Stufe (Abbildung
3.1.10). Durch Ausführen des Links sendet der Benutzer die RequestID. Daraufhin wird in der
Datenbank nachgesehen, ob eine zur RequestID zugehörige Passwortabfrage existiert. Ist dies nicht
der Fall, wird die Abarbeitung abgebrochen. Existiert die Passwortabfrage, so muss nun überprüft
werden, ob sie noch nicht abgelaufen ist. Ist diese Prüfung positiv, wird der Benutzer aufgefordert,
seinen Kontoschlüssel einzugeben. Mit dem Abschicken des Kontoschlüssels muss auch die
RequestID wieder mitgeschickt werden, weil ja der Benutzer mit jedem HTTPS­Request
identifiziert werden muss. Nachdem also der Benutzer in einem weiteren HTTPS­Request den
Kontoschlüssel gesendet hat, muss zu Beginn der Abarbeitung des HTTPS­Requests wieder die
RequestID überprüft werden. Wie besprochen hat der Benutzer nur eine bestimmte vorgegebene
Anzahl an Versuchen, den Kontoschlüssel einzugeben und damit das Passwort zu entschlüsseln.
Daher muss nun geprüft werden, ob die maximale Versuchsanzahl nicht überschritten wurde. Nach
der Prüfung muss dann die Anzahl bereits getätigter Versuche um 1 erhöht werden. Nun wird das
verschlüsselte Passwort aus der Datenbank geholt und zusammen mit dem Kontoschlüssel an das
Crypter­Modul zur Entschlüsselung weitergegeben. Konnte das Passwort nicht entschlüsselt werden
(dies kann einfach durch eine Überprüfung des Passwort­Formates geprüft werden), so hat der
Benutzer offensichtlich den Kontoschlüssel falsch eingegeben. In diesem Fall wird der Benutzer
darüber informiert, dass der eingegebene Kontoschlüssel falsch war. Konnte das Passwort
erfolgreich entschlüsselt werden, so wird es angezeigt.
3.2 Klassenmodellierung
In folgenden Abschnitten werden die Klassen, die für die Modellierung der Bergsportplattform
notwendig sind, im Detail besprochen.
3.2.1 Benutzergruppen
Nachfolgend werden alle Benutzergruppen aufgezeigt und diskutiert, die die Internetseite der
Bergsportplattform verwenden. Insbesondere werden auch die Rechte und Aufgaben der einzelnen
Benutzergruppen dargestellt. Abbildung 3.2.1 zeigt das zugehörige Klassendiagramm. Im
Klassendiagramm sind nur jene Benutzergruppen enthalten, von denen die Bergsportplattform
Daten aufnimmt, weil nur für solche Benutzergruppen Software implementiert wird.
Walter Sunk 33

3 Modellierung 30. August 2006
Benutzerrechte
Jede Benutzergruppe hat unterschiedliche Rechte. Die Rechte eines einzelnen Benutzers auf der
Bergsportplattform hängen daher davon ab, welcher Benutzergruppe er angehört.
Abbildung 3.2.1: Klassendiagramm zur Modellierung der Benutzergruppen
Person
Alle auf der Bergsportplattform angemeldeten Benutzer sind Personen. Eine jede angemeldete
Person hat einen Benutzernamen und ein Passwort. Wie in Abschnitt 2.2.3 besprochen wird das
Passwort zum einen als Hash (Feld Passwort) und zum anderen als zweiweg­verschlüsseltes
Passwort (Passwort2W) gespeichert. Zu jeder Person werden die Daten Anrede, Titel, Vorname,
Nachname und E­Mail Adresse aufgenommen. Um in der Datenbank nicht für jeden HTTPS­
Request einer Person mehrere Joins zum Bestimmen der Rechte der Person durchführen zu müssen,
werden die Rechte einer Person aus Effizienzgründen in dem eigenen Feld Berechtigung
gespeichert. Aus rechtlichen oder administrativen Gründen kann es notwendig sein, einen
Walter Sunk 34

3 Modellierung 30. August 2006
Benutzeraccount vorübergehend zu sperren. Zu diesem Zweck wird das Feld Accountfreigabe
eingeführt, das anzeigt, ob der Benutzeraccount frei verwendet werden kann (true) oder zur Zeit
gesperrt ist (false).
Besucher
Ein Besucher ist ein Benutzer, welcher die Bergsportplattform besucht, sich jedoch nicht anmeldet.
Besucher sollen Zugang zu Beispieltouren erhalten, damit sie sich selbst ein Bild vom Angebot der
Internetseite machen können. Außerdem sollen Besucher Zugang zu einem Informationsbereich
haben, der Auskunft über die Bergsportplattform und das gesamte Projekt gibt. Voraussetzung zum
Erwerben von Dokumentationen ist, dass sich Benutzer auf der Bergsportplattform anmelden.
Mitglieder
Mitglieder sind auf der Bergsportplattform angemeldete Personen. Zu jedem Mitglied werden die
Daten Geburtsdatum*, Straße*, PLZ*, Wohnort*, Staat*, Telefonnummer, Handynummer und
Homepage aufgenommen, wobei die mit * gekennzeichneten Felder verpflichtend sind. Das Feld
News gibt an, ob das Mitglied den Newsletter erhalten möchte. Jedes Mitglied wird durch einen
Werber geworben (sollte das Mitglied in der Realität durch keinen Werber geworben werden, dann
erhält es einen Default­Werber). Aus rechtlichen Gründen (zum Nachweis der Daten gegenüber
Werbern) und um den Werber eines Mitglieds besser bestimmen zu können, werden die Daten
Werbertext und WerberHttpReferer zu jedem Mitglied gespeichert. Beide Daten kommen aus der
Anmeldung des Mitglieds. Der Werbertext ist jener Text, den das Mitglied während der Anmeldung
auf die Frage, wie er oder sie zur Bergsportplattform gekommen sei, eingeben muss. Der
WerberHttpRefer ist jene URL, von der aus das Mitglied die Internetseite der Bergsportplattform
betreten hat (durch den Referer können besonders jene Werber einfach bestimmt werden, die durch
einen Link auf Ihrer Internetseite auf die Internetseite der Bergsportplattform referenzieren).
Zwecks möglichen zukünftigen Statistikauswertungen wird der Anmeldezeitpunkt
(RegistrierungsTimestamp) eines jeden Mitglieds gespeichert.
Kunden
Kunden sind angemeldete Mitglieder der Bergsportplattform, die Dokumentationen nach Aufladung
eines Guthabens erwerben können. Kunden haben Zugang zum Mitgliedsbereich, in welchem Sie
alle ihre erworbenen Dokumentationen einsehen können. Im weiteren können Kunden im
Mitgliedsbereich auch ihre getätigten Käufe einsehen. Jeder Kunde hat somit ein eigenes
Kundenkonto. Kunden können entweder Privat­ (default) oder Geschäftskunden sein.
Autoren
Autoren sind angemeldete Mitglieder, die das Recht haben, Dokumentationen zu verfassen und (mit
Zustimmung ihres Autorenbetreuers) zu publizieren. Autoren können auch im Team arbeiten und
gemeinsam Tourenalben verfassen. Autoren können im Mitgliedsbereich sämtliche Umsätze
einsehen. Jeder Autor hat somit ein eigenes Autorenkonto. Um Kunden Auskunft über Autoren
geben zu können, werden zu jedem Autor die Daten Verein, Alpinausbildung und alpine
Erfahrungen gespeichert. Aus rechtlichen Gründen müssen noch ein paar weitere Geschäftsdaten
des Autors, wie in Abbildung 3.2.1 gezeigt, aufgenommen werden.
Walter Sunk 35

3 Modellierung 30. August 2006
Autorenbetreuer
Jeder Autor erhält einen für ihn zuständigen Autorenbetreuer, der ebenfalls ein angemeldetes
Mitglied ist. Dokumentationen werden nur mit der Zustimmung des Betreuers veröffentlicht. Wenn
Autoren Dokumentationen veröffentlichen möchten, müssen diese also die Zustimmung ihres
Betreuers einholen. Der Autorenbetreuer hat somit folgende Aufgaben:
• Er steht dem Autor für Fragen per E­Mail zur Verfügung. Zu diesem Zweck muss ein
Autorenbetreuer eine eigene geschäftliche E­Mail Adresse (Feld OfficeEmail) bekanntgeben.
• Er legt neue Dokumentationen an und kann alte Dokumentationen löschen.
• Er unterstützt den Autor beim Erstellen seiner ersten Dokumentationen.
• Er führt Qualitätsprüfungen der Dokumentationen durch.
• Er erteilt nach positiver Qualitätsprüfung die Zustimmung zur Veröffentlichung von
Dokumentationen.
Autorenbetreuer können im Mitgliedsbereich sämtliche Umsätze einsehen. Jeder Autorenbetreuer
hat somit ein eigenes Autorenbetreuerkonto.
Übersetzer
Übersetzer sind angemeldete Mitglieder, die Dokumentationen von Autoren übersetzen. Ein Autor
kann seine Übersetzer selbst bestimmen. Übersetzer dürfen nur jene Teile einer Dokumentation
updaten, die übersetzbar sind. Ein Autor kann überdies bestimmen, welche Sprache der jeweilige
Übersetzer updaten darf. Übersetzer dürfen prinzipiell nur bestimmte Ausgangssprachen in
bestimmte Zielsprachen übersetzen. Aus diesem Grund werden die Ausgangssprachen und die
Zielsprachen eines jeden Übersetzers als Set gespeichert. Damit ein Übersetzer von der
Administration kontaktiert werden kann, muss er eine eigene geschäftliche E­Mail Adresse (Feld
OfficeEmail) bekanntgeben.
Werber
Ein Werber macht Werbung für die Bergsportplattform. Der Werber erhält von den Einkäufen
geworbener Kunden eine Provision von den Netto­Einkaufspreisen. Der Werber wird entweder über
den HTTP­Referer (die URL, auf der der Werber einen Link zur Bergsportplattform anbringt) oder
über den Werbertext, den der Kunde bei der Anmeldung eingeben muss, identifiziert. Auf Wunsch
des Werbers wird dieser über jeden neu geworbenen Kunden per E­Mail informiert (Felder
Benachrichtigung, BenachrichtigungsEmail, Benachrichtigunssprache). Dadurch ist es möglich,
dass der Werber selbst die Funktionsweise der Internetseite prüfen und sich somit von der
Funktionalität selbst überzeugen kann.
Mitarbeiter
Mitarbeiter sind Personen, die bei der Bergsportplattform mitarbeiten, jedoch nicht
notwendigerweise angemeldet sein müssen. Mitarbeiter erhalten eine E­Mail Adresse von der
Bergsportplattform.
Administratoren
Administratoren sind für die technische Realisierung und Verwaltung der Plattform zuständig.
Administratoren bekommen einen SSH­Zugang zum Server.
Walter Sunk 36

3 Modellierung 30. August 2006
3.2.2 Tourtypen
Im Bergsport trifft man auf eine Vielfalt von verschiedenen Arten von Touren, die im folgenden als
Tourtypen bezeichnet werden. Tourtypen sind z.B. Wanderungen, Hochtouren, Skitouren,
Skihochtouren, Schneeschuhwanderungen, Klettersteige, Klettertouren, Eisklettertouren,
Mountainbiketouren, etc.. Jeder Tourtyp hat bestimmte Eigenschaften. Alle Tourtypen haben jedoch
auch bestimmte Eigenschaften gemeinsam. Die gemeinsamen Eigenschaften aller Tourtypen
werden im folgenden generalisiert und als Tour bezeichnet.
Mit Eröffnung der Bergsportplattform im Sommer 2006 soll diese gemäß der Aufgabenstellung in
Abschnitt 1.2 in der Lage sein, Wanderungen und Hochtouren zu verwalten. Das Hinzufügen von
weiteren Tourtypen soll jedoch bereits geplant werden und die Implementierung soll eine einfache
Erweiterung der Plattform auf weitere Tourtypen ermöglichen.
Bewertungsskalen
Für viele Tourtypen existieren eigene Bewertungsskalen, die die Schwierigkeit und Anforderungen
der jeweiligen Tour bewerten. Der Schweizer Alpen Club ist ein international anerkannter
Herausgeber solcher Bewertungsskalen, die auf [SAC] veröffentlicht sind. Aus diesem Grund soll
die Schwierigkeit von Touren auf der Bergsportplattform nach den Bewertungsskalen des
Schweizer Alpen Clubs bewertet werden, falls von diesem eine Bewertungsskala zur Verfügung
steht. Ansonsten finden andere international anerkannte Skalen Anwendung. Im folgenden werden
die auf der Bergsportplattform zur Zeit verwendeten Bewertungsskalen erläutert.
Bewertungsskala für Wanderungen
Wanderungen werden in ihrer Gesamtheit nach der international anerkannten Wanderskala des
Schweizer Alpen Clubs [SAC] bewertet. Die Stufen der Wanderskala sind T1 (Wandern), T2
(Bergwandern), T3 (Anspruchsvolles Bergwandern), T4 (Alpinwandern), T5 (Anspruchsvolles
Alpinwandern) und T6 (Schwieriges Alpinwandern), wobei einzelne Zwischenstufen durch +/­
Vorzeichen bewertet werden können (z.B. T3+ oder T4­).
Bewertungsskala für Hochtouren
Hochtouren werden in ihrer Gesamtheit nach der international anerkannten Hochtourenskala des
Schweizer Alpen Clubs [SAC] bewertet. Die Stufen der Hochtourenskala sind L (leicht), WS
(wenig schwierig), ZS (ziemlich schwierig), S (schwierig), SS (sehr schwierig), AS
(außerordentlich schwierig) und EX (extrem schwierig), wobei einzelne Zwischenstufen durch +/­
Vorzeichen bewertet werden können (z.B. ZS+ oder S­).
Bewertungsskala für das Felsgelände
Das Felsgelände wird nach der international anerkannten UIAA­Skala bewertet [UIAA]. Die UIAA­
Skala verwendet römische Ziffern (I,II,III,IV,V,VI,VII). Zwecks Übersichtlichkeit werden auf der
Bergsportplattform die entsprechenden arabischen Ziffern (1,2,3,4,5,6,7) verwendet. Eine
ausführliche Erklärung der UIAA­Skala in Deutsch kann von der Internetseite des Schweizer
Alpen­Clubs [SAC] heruntergeladen werden.
Bewertungsskala für Klettersteige
Klettersteige oder Klettersteig­Passagen werden nach der im europäischen Alpenraum
Walter Sunk 37

3 Modellierung 30. August 2006
gebräuchlichen 5­teiligen Klettersteigskala von A bis E angegeben. Eine ausführliche Erklärung der
Klettersteigskala in Deutsch findet man z.B. auf der Klettersteigseite von Wikipedia [KstWiki].
Grundlegende Klassenmodellierung
Die grundlegende Klassenmodellierung der verschiedenen Tourtypen zeigt Abbildung 3.1.2. Aus
Gründen der Übersichtlichkeit werden die Eigenschaften der Tourtypen erst nachfolgend in
Abbildung 3.2.3 beschrieben. Jede Tour wird von einem bestimmten Autor verfasst. Die
Gemeinsamkeiten aller Tourtypen werden zur Klasse Tour generalisiert. Jeder spezielle Tourtyp
wird mit einer eigenen Klasse modelliert und ist eine Spezialisierung der Klasse Tour. Jeder
Tourtyp bekommt somit die Eigenschaften der Klasse Tour und fügt weitere Eigenschaften, wie
z.B. die Bewertung nach einer Bewertungsskala hinzu.
Abbildung 3.2.2: Klassendiagramm der verschiedenen Tourtypen
Skihochtouren bilden eine kleine Ausnahme. Sie bilden eine Mischung aus Hochtouren und
Skitouren. Hochtouren werden im Sommer begangen und führen in der Regel über Gletscher.
Skitouren werden im Winter begangen und führen in der Regel über keine Gletscher. Eine
Skihochtour wird im Winter begangen und führt in der Regel über einen Gletscher. Skihochtouren
sind daher eigentlich Spezialisierungen sowohl von der Klasse Hochtour als auch von der Klasse
Skitour. Um die Probleme der Mehrfachvererbung auszuschließen, wird die Klasse Skihochtour als
Spezialisierung der Klasse Hochtour gesehen, implementiert dafür aber das Interface ISkitour,
welches ebenfalls von der Klasse Skitour implementiert wird und die wichtigsten Eigenschaften
einer Skitour widerspiegelt.
Modellierung der Eigenschaften
Die Modellierung der Eigenschaften der Tourtypen zeigt Abbildung 3.2.3. Nachdem die
Bergsportplattform mehrere Sprachen unterstützt, müssen auch Textfelder in mehreren Sprachen
vorhanden sein. Alle diese Textfelder sind in Abbildung 3.2.3 mit einem * gekennzeichnet. Der
Zusatz „_Erg“ bei einigen Textfeldern bedeutet, dass hier der Autor zusätzlichen Text in Form einer
Ergänzung hinzufügen kann. Ergänzungen eigenen sich besonders gut, um Bewertungen einer Tour
zu kommentieren. Nachfolgend werden die wichtigsten Eigenschaften der verschiedenen Klassen
besprochen und erklärt.
Walter Sunk 38

3 Modellierung 30. August 2006
Klasse Tour
Gemäß Abschnitt 1.3 ist eine Tour ist eine Unternehmung im freien Gelände oder im Gebirge. Jede
Tour wird eindeutig durch eine Nummer identifiziert. Sie besitzt einen Namen und einen
ergänzenden Namen (Feld Name_Erg). Der Name der Tour soll mit dem Hauptziel der Tour in
Verbindung gebracht werden, während der ergänzende Namen einen Hinweis auf den Aufstiegsweg
geben soll. Mögliche Kombinationen der Form „Name – Name_Erg“ sind z.B. „Großglockner ­
Normalweg von Kals“ oder „Großglockner – Aufstieg über den NW­Grat“.
Abbildung 3.2.3: Modellierung der Eigenschaften der Tourtypen
Zu jeder Tour muss der Umfang notiert werden, im Falle dass dieser aus dem Namen (inkl.
Name_Erg) der Tour nicht klar ersichtlich sein. Dies ist z.B. für anspruchsvolle Touren sinnvoll, bei
denen der Aufstieg über anspruchsvolles Gelände führt (z.B. über einen Grat) und der Abstieg dann
über einen Normalweg (z.B. einen Wanderweg) verläuft. Meistens ist der Normalweg bereits in
einer eigenen Dokumentation vorhanden und braucht daher nicht extra neu dokumentiert zu werden
(oft ist für fortgeschrittene Tourengeher auch nur der anspruchsvolle Aufstieg interessant). In einem
solchen Fall kann im Umfang der anspruchsvollen Tour notiert werden, dass die Dokumentation nur
den Aufstieg beschreibt, der Abstieg der Tour jedoch in einer anderen Dokumentation beschrieben
wird. Oft kommt es auch vor, dass Hüttenzustiege zwecks Übersicht in einer eigenen
Dokumentation beschrieben werden, auch das kann im Umfang notiert werden.
Eine kurze Charakteristik der Tour soll Tourengehern helfen, einen ersten Eindruck von der Tour zu
bekommen. Zu jeder Tour werden außerdem Ausgangspunkt und dessen Höhe (Ausgangspunkt_m),
Endpunkt und dessen Höhe (Endpunkt_m), die Höhenmeter im Aufstieg (Ges_Hm, Ges_Hm_Erg),
Walter Sunk 39

3 Modellierung 30. August 2006
die Länge des Weges in Kilometern (Ges_km, Ges_km_Erg), der Zeitaufwand (Ges_t, Ges_t_Erg),
die Exposition (Exposition, Exposition_Erg) und im Handel erhältliches Kartenmaterial gespeichert.
Die Freigabe­Felder sind entsprechend den Freigabemöglichkeiten im Öffentlichkeitsupdate aus
Abschnitt 2.1.5 zu interpretieren. Publizieren bedeutet demnach, dass die Tour öffentlich gefunden
wird, öffentliche Anzeige (entspricht der Veröffentlichung) in einer Sprache bedeutet, dass die
öffentlichen Basisdaten der Tour angezeigt werden. Alle Freigaben werden erst mit der
Zustimmung des zugehörigen Autorenbetreuers wirksam, daher existiert für jedes Freigabefeld des
Autors ein eigenes Freigabefeld für die Zustimmung des Betreuers.
Gemäß Abschnitt 3.1.2 hat jede Tour im weiteren eine Beschreibung (bestehend aus Anreise und
Zufahrt, Tourenverlauf, Erlebnissen und Eindrücken). Aufgrund dessen, dass diese Inhalte beliebig
lange Texte sein können, werden sie nicht durch eigene Klassen repräsentiert, sondern in eigenen
Textdateien im Dateisystem und nicht in der Datenbank abgelegt. Deshalb scheinen diese Inhalte
auch nicht im Klassendiagramm auf.
Klasse Wanderung
Nachdem Wanderungen von einer Vielzahl von Menschen begangen werden, wird bei
Wanderungen auf die Beschreibung der Wegbeschaffenheit Wert gelegt (Feld Wegbeschaffenheit).
Dies ist insbesonders bei relativ einfachen Wanderungen sinnvoll, damit Wanderer z.B.
entsprechendes Schuhwerk aussuchen oder beurteilen können, ob der Weg auch für das Mitnehmen
von Kindern oder Kleinkindern geeignet ist.
Wie bereits diskutiert wird die Gesamtschwierigkeit von Wanderungen nach der SAC­Wanderskala
[SAC] bewertet. Zu diesem Zweck besitzt eine Wanderung die Felder S_W, SSt_W und S_Erg_W.
Im Feld S_W wird die Schwierigkeit (T1 bis T6) abgelegt, im Feld SSt_W die Zwischenstufe
(keine, +, ­). Wanderungen können einfache Felspassagen beinhalten, die bereits ein wenig
Klettergeschick erfordern. Wie besprochen werden Felspassagen nach der UIAA­Skala [UIAA]
bewertet. Zu diesem Zweck besitzt eine Wanderung die Felder Fels_S, Fels_SSt und Fels_Erg. Im
Feld Fels_W wird die Schwierigkeit (1 bis maximal 3) abgelegt, im Feld Fels_SSt die
Zwischenstufe (keine, +, ­). Im weiteren können Wanderungen auch einfache Klettersteige
enthalten, wie besprochen, bewertet nach der im Alpenraum 5­teiligen Klettersteigskala. Zu diesem
Zweck besitzt eine Wanderung die Felder Klettersteig_S, Klettersteig_SSt und Klettersteig_Erg. Im
Feld Klettersteig_S wird die Schwierigkeit (A bis maximal C) abgelegt, im Feld Klettersteig_SSt
die Zwischenstufe (keine, +, ­). In den Ergänzungsfeldern („_Erg“) kann der Autor Anmerkungen
zur jeweiligen Schwierigkeit angeben (z.B. „fast durchgehend T2, eine Stelle T3“).
Klasse Hochtour
Hochtouren beinhalten an Zusatzinformation ebenfalls eine ausführliche Bewertung der
auftretenden Schwierigkeiten. Die Gesamtschwierigkeit von Hochtouren wird wie besprochen nach
der SAC­Hochtourenskala [SAC] bewertet. Zu diesem Zweck besitzt eine Hochtour die Felder S_H,
SSt_H und S_Erg_H. Im Feld S_H wird die Schwierigkeit (L bis EX) abgelegt, im Feld SSt_H die
Zwischenstufe (keine, +, ­). Die Felder zur Bewertung der Schwierigkeiten im Fels sind dieselben
wie bei der Wanderung, nur dass nun die volle Skala (von 1 bis 7) zur Verfügung steht. Außerdem
wird bei Hochtouren die maximale Steilheit (in Grad) von Schneefeldern und Eisflächen
(Gletscheranstiege, Eisrinnen, Eiswände, etc.) in den Feldern Eis_Grad und Eis_Erg angegeben.
Walter Sunk 40

3 Modellierung 30. August 2006
Klassen Skitour, Skihochtour und Schneeschuhwanderung und Interface ISkitour
Gemäß der Aufgabenstellung in Abschnitt 1.2 wurden diese Klassen bereits in der Modellierung
berücksichtigt, jedoch aus Zeitgründen noch nicht gänzlich implementiert. Skitouren und
Skihochtouren werden vermutlich mit der Wintersaison 2006/2007 zur Verfügung stehen.
Der Aufbau der Klassen ist analog dem Aufbau von Wanderungen und Hochtouren zu verstehen. In
den Feldern werden wieder Angaben zur Schwierigkeit abgelegt. Als Grundlage für die Bewertung
dienen wieder die entsprechenden Bewertungsskalen des Schweizer Alpen Clubs [SAC]. Bei
Wintertouren ist eine Bewertung der Steilheit und der Exposition des Geländes und eine Bewertung
der damit verbundenen möglichen Lawinengefahr besonders zu berücksichtigen.
3.2.3 Klassenbeziehungen einer Tour
Im folgenden werden jene Klassen modelliert, die mit der Klasse Tour aus Abschnitt 3.2.2 in
Beziehung stehen. Das zugehörige Klassendiagramm ist in Abbildung 3.2.4 dargestellt. Felder, die
für jede Sprache einmal vorkommen, sind dabei mit einem * gekennzeichnet.
Fotos und Tourenfotos
Unter einem Tourenfoto versteht man ein Foto, dass zu einer Tour hinzugefügt wurde. Jedes Foto
hat eine eindeutige Nummer, einen Dateinamen und kann beschriftet werden. Ein Tourenfoto hat
eine Reihenfolge, in der es in der Tourendokumentation angezeigt wird. Die Reihenfolge der
einzelnen Tourenfotos kann dabei vom Autor bestimmt werden. Zu jedem Tourenfoto wird die Zeit
festgehalten, wann es zum letzten Mal upgedatet wurde (LastUpdateTime). Dies ist wichtig, damit
im Falle eines upgedateten Tourenfotos dem Browser eines Benutzers mitgeteilt werden kann, das
Tourenfoto nicht aus dem Cache, sondern vom Server zu laden.
Fototypen
Ein jedes Foto hat einen Fototyp. Dieser dient dazu, dass ein Benutzer den dargestellten Inhalt eines
Fotos besser in seine Vorstellung vom realen Tourenverlauf einbauen kann. Tabelle 3.2.1 zeigt die
Fototypen, die die Plattform unterstützt.
Abk. Typ Beschreibung
V Verlauf Ein Foto, das den Wegverlauf zeigt. Der Blick ist nach vorne gerichtet.
R Rückblick Ein Rückblick auf der Tour. Der Blick ist nach hinten gerichtet.
L lokal Ein Foto von einer bestimmten Stelle auf der Tour, z.B. ein Wegweiser.
Ü Übersicht Ein Foto, das weite Teile des Wegverlaufs bis zum gesamten Wegverlauf zeigt.
Z Ziel Ein lokales Foto vom Ziel der Tour, z.B. ein Gipfelkreuz.
A Aussicht Ein Foto, das eine Aussicht auf der Tour zeigt.
Tabelle 3.2.1: Übersicht über die Fototypen
Fotolinks
Wie in Abschnitt 3.1.2 beschrieben können Fotos derselben Tour untereinander verlinkt werden.
Dabei können in jedem Foto Links zu anderen Fotos derselben Tour angebracht werden. Das Foto,
in dem die Links angebracht werden, wird Source­Foto (srcFoto) genannt. Das jeweils verlinkte
Walter Sunk 41

3 Modellierung 30. August 2006
Zielfoto wird Destination­Foto (destFoto) genannt. Ein Fotolink kann also als eine n:m Beziehung
unter der Bedingung modelliert werden, dass die Tourennummer des srcFoto und die des destFoto
gleich sind. Um die Links der Destination­Fotos im Source­Foto einzeichnen zu können, müssen für
jedes Destination­Foto die x/y Koordinaten im Source­Foto gespeichert werden.
Abbildung 3.2.4: Modellierung der Klassenbeziehungen einer Tour
Karten und Tourenkarten
Unter einer Tourenkarte versteht man eine Karte, die zu einer Tour hinzugefügt wurde. Jede Karte
hat eine eindeutige Nummer, einen Dateinamen, einen Maßstab und kann beschriftet werden. Eine
Tourenkarte hat eine Reihenfolge, in der sie in der Tourendokumentation angezeigt wird. Die
Reihenfolge der einzelnen Tourenkarten kann dabei vom Autor bestimmt werden. Wie bei den
Tourenfotos wird zu jeder Tourenkarte die Zeit festgehalten, wann sie zum letzten Mal upgedatet
wurde (LastUpdateTime). Dies ist wichtig, damit im Falle einer upgedateten Tourenkarte dem
Walter Sunk 42

3 Modellierung 30. August 2006
Browser eines Benutzers mitgeteilt werden kann, die Tourenkarte nicht aus dem Cache, sondern
vom Server zu laden.
Kartentyp bzw. Kartenhersteller
Der Kartentyp beschreibt den Hersteller der Karte (diese Klasse könnte daher auch Kartenhersteller
heißen). Zwecks Konformität zu den anderen auftretenden Typen wurde jedoch die Bezeichnung
Kartentyp gewählt. Ein Kartentyp ist eindeutig identifiziert durch eine Nummer, hat eine
Bezeichnung und einen Namen. Folgende Kartentypen sollen anfänglich unterstützt werden: Karten
vom Bundesamt für Eich­ und Vermessungswesen [BEV] und Karten, die der Autor selbst
hergestellt hat (in letzterem Fall ist der Kartentyp „Eigenproduktion“ zu vergeben).
Kartenfotolinks
Wie in Abschnitt 3.1.2 können in jeder Karte Links zu anderen Fotos derselben Tour angebracht
werden. Die Karte, in der die Links angebracht werden, wird Source­Karte (srcKarte) genannt. Das
jeweils verlinkte Zielfoto wird Destination­Foto (destFoto) genannt. Ein Kartenfotolink kann also
als eine n:m Beziehung zwischen den Klassen Tourenfoto und Tourenkarte unter der Bedingung
modelliert werden, dass die Tourennummer der srcKarte und die des destFoto gleich sind. Um die
Links der Destination­Fotos in der Source­Karte einzeichnen zu können, müssen für jedes
Destination­Foto die x/y Koordinaten in der Source­Karte gespeichert werden.
Zieltypen, Ziele, Tourenziele, Tourenstützpunkte
Unter einem Ziel versteht man ein konkretes Ziel auf einer Tour, z.B. den Gipfel des
Großvenedigers, den Gosausee oder die Lienzer Hütte. Ein Ziel hat einen Namen und stets eine
Höhe, die für Tourengeher stets von großem Interesse ist. Ein Tourenziel ist ein Ziel, das zu einer
Tour hinzugefügt wurde. Aus Effizienzgründen wird zu jedem Ziel die Anzahl der Touren
gespeichert, zu denen es hinzugefügt wurde (Feld GesAnzTouren). Die Gesamtanzahl der Touren
ist damit gleichbedeutend mit der Anzahl der Tourenziele, in denen das Ziel vorkommt.
Ein Zieltyp beschreibt ein Ziel näher. Zieltypen können z.B. ein Gipfel, ein See, eine Hütte, ein
Wasserfall, eine Seilbahnstation, etc. sein. Ein Zieltyp wird eindeutig durch eine Nummer
identifiziert und durch einen Namen beschrieben. Ein Zieltyp kann selbst wieder einen bestimmten
Typ haben. Der Typ eines Zieltyps ist entweder „Gelände“ oder „Stützpunkt“. So sind z.B. ein
Gipfel, ein See und ein Wasserfall vom Typ „Gelände“, eine Hütte und eine Seilbahnstation jedoch
vom Typ „Stützpunkt“.
Die Unterscheidung zwischen dem Typ „Gelände“ und dem Typ „Stützpunkt“ ist aus folgendem
Grund wichtig. Alle Stützpunkte (konkrete Hütten, konkrete Biwaks, konkrete Gasthäuser, etc.)
können auch Ziele einer Tour sein. Umgekehrt können aber nicht alle Ziele auch Stützpunkte sein.
Ein Tourenziel ist somit genauer gesagt ein Ziel, das zu einer Tour hinzugefügt wurde und dessen
Zieltyp den Typ „Gelände“ oder „Stützpunkt“ hat. Ein Tourenstützpunkt ist ein Ziel, das zu einer
Tour hinzugefügt wurde und dessen Zieltyp jedoch nur den Typ „Stützpunkt“ hat.
Zu jedem Tourenziel und zu jedem Tourenstützpunkt kann der Autor der Tour eine kleine
Anmerkung (Felder Erg) notieren.
Walter Sunk 43

3 Modellierung 30. August 2006
Talorte und Tourentalorte
Talorte sind eindeutig identifiziert durch eine Nummer, haben einen Namen, einen Zusatz zum
Namen, eine Höhe und befinden sich oftmals in einem Tal. Ein typischer Talort ist z.B. Kals, am
Großglockner, im Kalser Tal, mit einer Höhe von 1324m.
Ein Tourentalort ist ein Talort, der zu einer Tour hinzugefügt wurde. Ein Tourentalort hat eine
Reihenfolge, in der er in der Tourendokumentation angezeigt wird. Die Reihenfolge der einzelnen
Tourentalorte kann vom Autor bestimmt werden. Zu jedem Tourentalort kann der Autor eine kleine
Anmerkung (Feld Erg) notieren. Talorte haben überdies auch einen Talorttyp. Dieser gibt an, ob der
Tourentalort ein Ausgangstalort, ein Endtalort oder ein dazwischenliegender Talort der Tour ist.
3.2.4 Klassenbeziehungen eines Albums
Ein Album beschreibt den Inhalt von Tourendokumentationen, die zu diesem Album hinzugefügt
werden können (aber nicht müssen). Ein Album kann daher ohne Tourendokumentation alleine
existieren. Die Klassenbeziehungen eines Albums zeigt Abbildung 3.2.5.
Abbildung 3.2.5: Modellierung der Klassenbeziehungen eines Albums
Klasse Album
Ein Album wird eindeutig identifiziert durch eine Nummer, hat einen Namen und eine (kurze)
Beschreibung. Eine „Name – Beschreibung“ Kombination eines Albums ist z.B. „Zentralpyrenäen,
Gavarnie – Die beliebtesten Wanderungen rund um Gavarnie.“ Ein jedes Album hat einen
hauptverantwortlichen Autor, der für die Inhalte des Albums verantwortlich ist.
Ein jedes Album hat einen Albumtyp. Der Typ sagt aus, welcher Typ von Touren sich im Album
befindet (bzw. befinden wird). Z.B. beinhaltet ein Wanderalbum Wanderungen, ein
Hochtourenalbum Hochtouren, etc..
Die Freigabe­Felder sind entsprechend den Freigabemöglichkeiten im Öffentlichkeitsupdate aus
Abschnitt 2.1.5 zu interpretieren. Die Freigabe Publizieren bedeutet daher, dass das Album
öffentlich gefunden werden kann, die Freigabe öffentliche Anzeige (diese entspricht der
Veröffentlichung) in einer Sprache bedeutet, dass die öffentlichen Basisdaten des Albums angezeigt
Walter Sunk 44

3 Modellierung 30. August 2006
werden. Für alle Freigaben ist die Zustimmung des zugehörigen Autorenbetreuers notwendig. Aus
diesem Grund ist für jedes Freigabefeld ein eigenes Freigabefeld für den Betreuer vorgesehen.
Zu jedem Album sollen die beteiligten Autoren gemäß Abschnitt 3.1.3 ein Vorwort verfassen
können, das über die Inhalte des Albums berichtet. Außerdem sollen Autoren Impressionsfotos zum
Album hinzufügen können. Aufgrund dessen, dass das Vorwort ein beliebig langer Text sein kann,
wird es nicht als Klasse modelliert, sondern in einer Textdatei im Dateisystem und nicht in der
Datenbank abgelegt. Nachdem Impressionsfotos keinerlei Zusatzinformation bedürfen, werden
diese ebenfalls direkt im Dateisystem gespeichert und werden daher auch nicht durch eine Klasse
repräsentiert. Aufgrund der beschriebenen Gründe scheinen die Impressionsfotos und das Vorwort
daher auch nicht im Klassendiagramm auf.
Albenautoren
Wie in der Aufgabenstellung in Abschnitt 1.2 beschrieben sollen Autoren die Möglichkeit haben,
Tourenalben gemeinsam zu erstellen. Zu diesem Zweck kann der hauptverantwortliche Autor eines
Albums anderen Autoren gestatten, Touren in das Album zu stellen. Autoren, die Touren in ein
Album stellen dürfen, sind Albenautoren. Der hauptverantwortliche Autor eines Albums ist somit
auch Albenautor seines Albums. Der hauptverantwortliche Autor kann andere Autoren zu
Albenautoren seines Albums machen, wodurch die anderen Autoren ihre Touren in das Album des
hauptverantwortlichen Autors stellen können.
Tourenalben
Gemäß Abschnitt 1.3 ist ein Tourenalbum eine Zusammenstellung ausgewählter Touren. In diesem
Fall sind Touren also bereits vorhanden. In der Modellierung könnte man daher ein Tourenalbum
dem ersten Anschein nach als ein Album, dem Touren hinzugefügt worden sind, interpretieren. Dies
ist jedoch nicht ganz korrekt, weil wie in diesem Abschnitt besprochen nur Albenautoren Touren zu
ihren Alben hinzufügen dürfen. Ein Tourenalbum ist somit eine Beziehung zwischen der Klasse
Tour und der Klasse Albenautor, wobei die Bedingung erfüllt sein muss, dass ein Albenautor nur
jene Touren zum Tourenalbum hinzufügen kann, die er selbst verfasst hat. Es muss also beim
Tourenalbum die Bedingung Tour.AutorBN == Albenautor.AutorBN erfüllt sein, wobei das Feld
AutorBN den Benutzernamen des Autors darstellt.
3.2.5 Übersetzer
Tourenübersetzer
Ein Tourenübersetzer übersetzt eine Tour in eine bestimmte Sprache. Genauer gesagt kann ein
Tourenübersetzer die Tour nur in jener Sprache updaten, für die er vom Autor die Berechtigung
dazu bekommen hat. Der Autor einer Tour kann demnach für seine Touren einzelne Übersetzer
bestimmen. Durch die Festlegung eines Übersetzers wird aus dem Übersetzer ein Tourenübersetzer.
Um sicherzustellen, dass Tourenübersetzer nur Daten in bestimmten Sprachen updaten können,
wird ein Tourenübersetzer nur für eine bestimmte Sprache definiert. Soll z.B. ein Übersetzer eine
Tour in 2 Sprachen updaten dürfen, dann müssen folglich 2 Tourenübersetzer definiert werden.
Abbildung 3.2.7 zeigt das zugehörige Klassendiagramm.
Tourenübersetzer dürfen nur jene Daten updaten, die auch wirklich übersetzbar sind. Beispielsweise
darf ein Tourenübersetzer die Schwierigkeitsbewertung einer Tour (z.B. bei einer Wanderung die
Felder S_W und SSt_W) nicht ändern können. Allgemein gesprochen darf also ein
Walter Sunk 45

3 Modellierung 30. August 2006
Tourenübersetzer alle mehrsprachigen Felder in Abbildung 3.2.3 (außer die Freigabefelder), alle mit
der Tour in Beziehung stehenden mehrsprachigen Felder in Abbildung 3.2.4 (die mehrsprachigen
Felder sind mit einem * gekennzeichnet), und die Beschreibungstexte der Tour in seiner Sprache
updaten, alle anderen Felder und Daten jedoch nicht.
Albenübersetzer
Für Albenübersetzer gilt sinngemäß dasselbe wie für Tourenübersetzer aus Abschnitt 3.2.5. Ein
Albenübersetzer übersetzt mehrsprachige Daten eines Album in eine bestimmte Sprache. Der
hauptverantwortliche Autor kann demnach für seine Alben einzelne Übersetzer bestimmen. Um
sicherzustellen, dass Albenübersetzer nur Daten in bestimmten Sprachen updaten können, wird ein
Albenübersetzer nur für eine bestimmte Sprache definiert. Abbildung 3.2.7 zeigt das zugehörige
Klassendiagramm.
Wie für die Tourenübersetzer aus Abschnitt 3.2.5 gilt auch für Albenübersetzer, dass diese nur jene
Daten updaten dürfen, die auch wirklich übersetzbar sind. Allgemein gesprochen darf also ein
Albenübersetzer alle mehrsprachigen Felder (außer natürlich die Freigabefelder) in Abbildung 3.2.5
(die mehrsprachigen Felder sind mit einem * gekennzeichnet) sowie das Vorwort des Albums in
seiner Sprache updaten, alle anderen Felder und Daten jedoch nicht.
3.2.6 Touren­ und Albenberechtigungen
Tourenberechtigungen
Abbildung 3.2.6: Klassendiagramm zur Modellierung eines Tourenübersetzers
Abbildung 3.2.7: Klassendiagramm zur Modellierung eines Albenübersetzers
Eine Tourenberechtigung gibt an, welcher Kunde die Daten welcher Tour beziehen darf. Eine
Tourenberechtigung wird in der Regel beim Kauf einer Tour vergeben. Aus rechtlichen Gründen
wird eine Tourenberechtigung immer nur für einen bestimmten Zeitraum ausgegeben (andernfalls
müsste rechtlich gesehen eine Tourendokumentation nach einem Kauf ewig am Server liegen (!)).
Walter Sunk 46

3 Modellierung 30. August 2006
Daher wird zu jeder Tourenberechtigung das Kaufdatum und das Ablaufdatum gespeichert.
Abbildung 3.2.8 zeigt das Klassendiagramm.
Der Kauf einer Tourendokumentationen erfolgt immer in einer bestimmten Sprache, auch wenn die
Dokumentation in mehreren Sprachen verfügbar ist. Dies ist deshalb so geregelt, weil auch
Übersetzer bezahlt werden müssen. Ein Übersetzer kann dadurch z.B. am Verkauf an den in seiner
Sprache verkauften Dokumentationen beteiligt werden. Daher wird eine Tourenberechtigung immer
in einer bestimmten Sprache vergeben. Die Klasse Tourenberechtigung muss daher noch um das
Feld Sprache erweitert werden.
Albenberechtigungen
Abbildung 3.2.8: Klassendiagramm zur Modellierung einer Tourenberechtigung
Für Albenberechtigungen gilt sinngemäß dasselbe wie für Tourenberechtigungen. Abbildung 3.2.9
zeigt das Klassendiagramm. Eine Albenberechtigung gibt an, welcher Kunde die Daten welcher
Alben beziehen darf. Dabei sind auch wirklich nur die Daten des entsprechenden Albums, und nicht
die Daten der zugehörigen Touren des zugehörigen Tourenalbums gemeint. Damit ein Kunde auch
auf die Touren des Tourenalbums zugreifen kann, muss er für diese Touren eine entsprechende
Tourenberechtigung besitzen. Aus diesem Grund wird beim Erwerb eines Tourenalbums nicht nur
die zugehörige Albenberechtigung vergeben, sondern es werden auch Tourenberechtigungen für alle
Touren des Tourenalbums eingetragen (gemäß der Aufgabenstellung aus Abschnitt 1.2 werden ja
beim Erwerb eines Tourenalbums alle Touren des Tourenalbums ebenfalls erworben).
Abbildung 3.2.9: Klassendiagramm zur Modellierung einer Albenberechtigung
Aus rechtlichen Gründen wird eine Albenberechtigung wie eine Tourenberechtigung ebenfalls
immer nur für einen bestimmten Zeitraum ausgegeben. Der Zeitraum der Albenberechtigung und
der Zeitraum der Tourenberechtigungen der Touren des Albums müssen gleich eingetragen werden,
Walter Sunk 47

3 Modellierung 30. August 2006
um Verwirrungen beim Kunden zu vermeiden. Daher wird zu jeder Albenberechtigung das
Kaufdatum und das Ablaufdatum gespeichert.
Der Kauf eines Albums erfolgt (wie in Abschnitt 3.2.5 beschrieben aufgrund der Bezahlung von
Übersetzern) immer in einer bestimmten Sprache, auch wenn das Album in mehreren Sprachen
verfügbar ist. Die Kaufsprache des Albums ist dabei natürlich auch gleichzeitig die Kaufsprache der
Touren, die sich im Album befinden. Dies bedeutet, dass die Albenberechtigung und die
zugehörigen Tourenberechtigungen genau in dieser Kaufsprache vergeben werden. Aus diesem
Grund muss auch die Klasse Albenberechtigung ein Feld Sprache enthalten.
3.2.7 Aufladung des Guthabens
Um Dokumentationen erwerben zu können, muss ein Kunde gemäß der Aufgabenstellung in
Abschnitt 1.2 zuerst ein Guthaben aufladen. Zwecks besseren Verständnis der vorliegenden Arbeit
wird das zugehörige Klassendiagramm zum Durchführen einer Aufladung im Überblick in
Abbildung 3.2.10 dargestellt. Die genaue Modellierung der Klassen und die Modellierung des
Ablaufs der Aufladung sind Inhalt der Praktikumsarbeit [WaSu06].
Damit eine Aufladung durchgeführt werden kann, müssen zuerst bestimmte Zahlungsdaten wie z.B.
die Zahlungsart (Zahlungsarten sind z.B. Kreditkarte, Banküberweisung, Payment Provider, etc.)
vom Kunden entgegengenommen werden. Diese Daten werden in der Klasse EAufladung (das steht
für „Erwartete Aufladung“ gesammelt). Nachdem der Kunde die gesammelten Zahlungsdaten
abgeschickt hat, entsteht rechtlich gesehen ein Vertrag zur Aufladung. Dieser Vertrag wird durch
die Klasse VAufladung (das steht für „Vertragliche Aufladung“) modelliert. Eine vertragliche
Aufladung ist wie in [WaSu06] beschrieben intern geringfügig anders aufgebaut als eine erwartete
Aufladung. Entsteht also ein Aufladevertrag, dann werden die Daten aus der entsprechenden
EAufladung in eine neue VAufladung übernommen. Die EAufladung kann danach gelöscht werden.
Nachdem EAufladung und VAufladung größtenteils gleich sind und sich nur in Einzelheiten
unterscheiden, wird eine Generalisierung der Gemeinsamkeiten der EAufladung und der
VAufladung zur Klasse Aufladung vorgenommen.
3.2.8 Gebiete
Abbildung 3.2.10: Klassendiagramm zur Modellierung einer Aufladung
Gemäß Abschnitt 3.1.1 kann ein Benutzer Touren durch eine Gebietsauswahl auswählen. Damit
eine Tour durch eine Gebietsauswahl gefunden werden kann, muss sie mindestens ein Ziel (genauer
ein Tourenziel, aus dem das Ziel hervorgeht) besitzen. Ein Ziel befindet sich dabei immer in einem
bestimmten Gebiet, was nun modelliert wird.
Walter Sunk 48

3 Modellierung 30. August 2006
Gemäß Abschnitt 3.1.1 befindet sich ein Ziel (z.B. der Hochschober) in einer Gebirgsgruppe (der
Schobergruppe), diese befindet sich in einem Gebirge (den Hohen Tauern), dieses befindet sich
wiederum in einer Gebirgsregion (den Ostalpen). Als Gebiet eines Ziels wird also die Kombination
Gebirgsregion – Gebirge – Gebirgsgruppe verstanden. Gebirgsregionen, Gebirge, Gebirgsgruppen
und Ziele werden durch eine Nummer eindeutig identifiziert und haben einen Namen, der
mehrsprachig ausgeführt ist.
Aus Effizienzgründen (um umfangreiche Joins in der Datenbank zu vermeiden) wird zu jeder
Klasse die Gesamtanzahl der Touren gespeichert. Zu beachten ist, dass für eine Tour mit mehreren
Tourenzielen, die Gesamtanzahl an Touren in den Klassen Gebirgsregion, Gebirge und
Gebirgsgruppe richtig erhöht werden muss. Zur Demonstration nehmen wir als Beispiel an, wir
unternehmen in Osttirol eine Hüttenwanderung mit den Zielen Glorer Hütte (Glocknergruppe) ­
Gernot Röhr Biwak (Schobergruppe) – Elberfelderhütte (Schobergruppe). Die Gesamtanzahl an
Touren aller Ziele muss um 1 erhöht werden. Die Wanderung besitzt Ziele in der Glocknergruppe
und Ziele in der Schobergruppe. Folglich muss die Gesamtanzahl an Touren in der Glocknergruppe
und in der Schobergruppe um 1 erhöht werden. Sowohl die Glocknergruppe als auch die
Schobergruppe befinden sich in den Hohen Tauern, folglich muss die Gesamtanzahl an Touren in
den Hohen Tauern um 1 (nicht um 2!) erhöht werden. Nachdem sich die Hohen Tauern in den
Ostalpen befinden, muss auch die Gesamtanzahl der Touren in den Ostalpen um 1 erhöht werden.
Jeder Tour kann gemäß Abschnitt 3.2.3 Talorte besitzen (ein Talort, der in Beziehung mit einer
Tour steht, ist gemäß Abschnitt 3.2.3 ein Tourentalort). Um einen Talort (z.B. Lienz in Osttirol)
auffinden zu können, erhält dieser eine Alpinregion (Osttirol). Um die Alpinregion auffinden zu
können, erhält diese wiederum ein Alpinstaat (Österreich). Alpinstaaten sind Staaten, in denen
alpine Touren durchgeführt werden können, also im wesentlichen solche Staaten, die Berge
besitzen. Ein Alpinstaat ist daher eine Spezialisierung eines Staates.
Abbildung 3.2.11 zeigt das Klassendiagramm für die Gebietsauswahl (also zum Auffinden von
Zielen) und das Klassendiagramm für die Auffindung von Talorten.
Abbildung 3.2.11: Klassendiagramme zur Modellierung zum Auffinden von Zielen und Talorten
Walter Sunk 49

3 Modellierung 30. August 2006
3.2.9 PDF­Dokumente
Wie in Abschnitt 3.1.2 beschrieben können zu jeder Tour zwei PDF­Dokumente heruntergeladen
werden. Aus Platzgründen am Server (das Beschreibungs­PDF kann bis zu 5MB haben, das Foto­
PDF kann bis zu 25MB haben) und weil sich der Inhalt der PDF­Dokumente ändern kann, werden
diese nach einem entsprechenden HTTP­Request dynamisch generiert. Die Generierung eines PDF­
Dokuments benötigt jedoch einige Rechenleistung des Servers. Würden zu viele PDF­Dokumente
zur gleichen Zeit heruntergeladen werden, dann könnte es zu einer Überlastung des Servers
kommen. Aus diesem Grund muss die Anzahl an PDF­Dokumente, die gleichzeitig generiert
werden, beschränkt werden. Dies wird dadurch erreicht, dass für einen bestimmten Benutzer nur
eine bestimmte Anzahl an HTTP­Requests zur PDF Generierung erlaubt sind.
Um die entsprechenden HTTP­Requests eines Benutzers aufzuzeichnen, muss dieser Benutzer
identifiziert werden. Nachdem z.B. Beispieltouren öffentlich zugänglich sind, und der Benutzer
daher zur Generierung der PDF­Dokumente der Beispieltouren nicht eingeloggt sein muss, wird der
Benutzer anhand seiner IP­Adresse identifiziert. Man könnte den Benutzer auch anhand eines
Cookies identifizieren. Nachdem aber Cookies leichter zu manipulieren sind als IP­Adressen, wird
aufgrund von möglichen Denial­of­Serivce Attacken (es könnte versucht werden, durch den
Download zu vieler PDF­Dokumente eine Überlastung des Servers herbeizuführen, wodurch der
Server dann keine Anfragen mehr beantworten könnte) die Identifizierung mittels IP­Adresse
vorgezogen. Sollten (was sehr unwahrscheinlich ist) mehrere Benutzer gleichzeitig ein PDF
herunterladen wollen, die dieselbe IP­Adresse haben, dann kann es mitunter vorkommen, dass ein
Benutzer warten und den Download später durchführen muss.
Im folgenden wird ein HTTP­Request zur Generierung eines PDF­Dokuments mit nachfolgendem
Download des PDF­Dokuments ein „PDF­Request“ genannt. Ein PDF­Request wird durch die
Klasse PDFRequest wie in Abbildung 3.2.12 gezeigt modelliert. Um zu verhindern, dass ein
Benutzer zu viele PDF­Requests ausführt, werden die PDF­Requests eines Benutzers (also einer IP­
Adresse) innerhalb eines vorgegebenen Zeitfensters (REQUEST_WINDOW) gezählt. Die Anzahl
der gleichzeitig generierten PDF­Dokumente darf dabei eine vorgegebene maximale Anzahl nicht
überschreiten (MAX_PDF_REQUESTS). Beispielsweise bedeuten ein Zeitfenster von 300
Sekunden und eine maximale Anzahl von 5 PDF­Requests, dass innerhalb der letzten 300 Sekunden
ein Benutzer (eine IP­Adresse) maximal 5 PDF­Requests ausführen darf. Um die Anzahl der bereits
getätigten PDF­Requests innerhalb des Zeitfensters überhaupt zählen zu können, muss bekannt sein,
wann der PDF­Request ausgeführt wurde. Zu diesem Zweck wird die Zeit des PDF­Requests in
dem Feld RequestTimestamp gespeichert..
Abbildung 3.2.12: Klassendiagramm zur Modellierung eines PDF­Requests
Die Klasse PDFRequestHandler ist eine Sammlung von Methoden zum Verwalten der PDF­
Requests in der Datenbank. Die Definitionen der Methoden sollten selbsterklärend sein.
Walter Sunk 50

3 Modellierung 30. August 2006
3.2.10 Werber­Domains
Gemäß Abschnitt 3.2.1 können Werber für die Bergsportplattform Werbung machen. Werber
machen dabei Kunden auf die Bergsportplattform aufmerksam. Wenn sich ein Kunde auf der
Bergsportplattform anmeldet, erhält er einen Werber. Sollte ein Kunde keinen Werber haben,
bekommt er einen Default­Werber.
Eine Möglichkeit, den Werber eines Kunden zu identifizieren, besteht über den HTTP­Referer des
Kunden. Der HTTP­Referer ist dabei jene URL, auf welcher der Werber einen Link zur
Bergsportplattform anbringt. Die Domain des HTTP­Referers wird im folgenden Werber­Domain
genannt (z.B. im HTTP­Referer „http://www.werber.com/links/partnerseiten.html“ ist die Werber­
Domain „werber.com“). Um den Werber aus dem HTTP­Referer heraus identifizieren zu können,
müssen also Aufzeichnungen darüber geführt werden, welche Werber­Domain zu welchem Werber
gehört. Eine jede Werber­Domain hat dabei genau einen Werber. Umgekehrt kann jeder Werber
(muss aber nicht) eine Werber­Domain auf der Bergsportplattform eintragen lassen. Abbildung
3.2.13 zeigt das zugehörige Klassendiagramm.
Die Klasse WerberDomainHandler verwaltet Werber­Domains in der Datenbank. Aus
Sicherheitsgründen werden Werber­Domains von einem Administrator direkt in die Datenbank
eingetragen. Aus diesem Grund enthält die Klasse WerberDomain keine insert, update oder delete
Methoden für Werber­Domains. Nachdem sich also ein neuer Benutzer angemeldet hat, kann mit
Hilfe der Funktion sucheWerber() möglicherweise der Werber des Benutzers festgestellt werden.
3.2.11 Ausgewählte Hilfsklassen
Im folgenden werden die wichtigsten zur Anwendung kommenden Hilfsklassen kurz diskutiert.
Klasse ImageUtilities
Abbildung 3.2.13: Klassendiagramm zur Modellierung der Werber­Domains
Gemäß Abschnitt 2.1.5 können Autoren Fotos über FTP auf den Server der Bergsportplattform
hinaufladen. Aus Sicherheitsgründen darf der Dateiname hinaufgeladener Fotos nur aus bestimmten
Zeichen bestehen, daher muss der Dateiname der Fotos überprüft werden. Damit Fotos in den
einzelnen Dokumentationen einheitlich sind, müssen diese alle dieselben Pixel­Abmessungen
haben. Um z.B. Thumbnails von Fotos erzeugen zu können, müssen Fotos komprimiert werden
können. Es ist sinnvoll, diese fotospezifischen Funktionen in einer gemeinsamen Klasse zu kapseln,
um gegebenenfalls Änderungen im Sourcecode nur an einer Stelle durchführen zu müssen. Zu
diesem Zweck wird die Klasse ImageUtilities gemäß Abbildung 3.2.14 definiert, welche die
notwendigen Funktionen zur Verfügung stellt.
Die Funktion checkImgFilename() prüft einen Dateinamen eines Fotos und gibt im Fehlerfall eine
Fehlermeldung in der richtigen Sprache zurück. Die Funktion checkImgSize() prüft die Pixel­
Walter Sunk 51

3 Modellierung 30. August 2006
Abmessungen eines Fotos (die Parameter xRequired und yRequired sind die gewünschten
Abmessungen) und gibt im Fehlerfall ebenfalls eine Fehlermeldung in der richtigen Sprache zurück.
Dabei ist es egal, ob es sich um ein Hochformat oder um ein Querformatfoto handelt. Die Funktion
compressImage() komprimiert ein Foto auf die in den Parametern x und y angegebenen Pixel­
Abmessungen. Dabei gibt der Parameter inPath an, wo sich das Foto zur Zeit befindet, und der
Parameter outPath, wo das komprimierte Foto abgelegt werden soll. Nachdem Fotos im
Dateisystem vielleicht nicht vorhanden sind oder die Kompression z.B. aufgrund von
Zugriffsrechten nicht möglich ist, kann es vorkommen, dass diese Funktion eine Exception wirft.
Klasse Mailer
Die Klasse Mailer besteht im wesentlichen aus der einzigen Klassenfunktion sendMail(), die eine
Kommunikation mit dem Mailserver aufbaut und eine E­Mail verschickt. Die in sendMail() intern
verwendeten Funktionen werden alle von der verwendeten Scriptsprache (in unserem Fall ist das
PHP) zur Verfügung gestellt. Es ist daher eigentlich nicht notwendig, extra eine Klasse Mailer zu
definieren. Die Einführung der Klasse macht jedoch Sinn, weil dadurch Änderungen an der
Kommunikation mit dem Mailserver an zentraler Stelle vorgenommen werden können.
Klasse TimestampFactory
Die Klasse TimestampFactory definiert einige wichtige Funktionen zum Umwandeln von
Timestamps in der Datenbank in Timestamps der verwendeten Scriptsprache (in unserem Fall PHP)
und umgekehrt. Außerdem bietet die Klasse die Möglichkeit, Zeitangaben zu generieren und in
verschiedene Formate zu formatieren. Nachdem die notwendigen Funktionen von der Scriptsprache
und vom konkreten Anwendungsfall abhängig sind, wird auf die Darstellung eines
Klassendiagramms verzichtet. Wie auch bei der Klasse Mailer könnte auf die Klasse
TimestampFactory verzichtet werden. Aus Gründen der Kapselung der Funktionalitäten an zentraler
Stelle ist die Definition dieser Klasse jedoch sinnvoll.
Klasse SQLQuery
Diese Klasse stellt eine Funktion query() zur Verfügung, die SQL­Queries in der verwendeten
Datenbank durchführt. Im Fehlerfall wird eine Exception geworfen. Die Klasse wird definiert, um
SQLQueries und Änderungen im Sourcecode an einer zentralen Stelle durchführen zu können.
3.2.12 Buchhaltung
Abbildung 3.2.14: Die Klasse ImageUtilities
Das Buchhaltungssystem ist dafür verantwortlich, dass die Einnahmen aus Käufen sowie
aufgeladenen Kundenguthaben richtig verwaltet werden. Dabei soll das System der doppelten
Buchhaltung wie in [EfBh04] beschrieben zur Anwendung kommen. Eine andere und einfachere
Möglichkeit wäre auch, das System der einfachen Buchhaltung zu verwenden. Das System der
doppelten Buchhaltung wird jedoch bevorzugt, weil dadurch gemäß [EfBh04] Fehler in der
Walter Sunk 52

3 Modellierung 30. August 2006
Buchhaltung einfach erkannt werden können.
Gemäß [EfBh04] besteht das System der doppelten Buchhaltung aus den 4 Teilsystemen Vermögen,
Fremdkapital, Aufwände und Erträge. Jeder Benutzer und jedes Service auf der Bergsportplattform
erhält ein eigenes Konto. Ein Konto ist im wesentlichen eine Sammlung von Buchungen. Alle
Buchungen werden in der Datenbank gespeichert und untereinander in Bezug gebracht. Im Modell
müssen daher nur Buchungen berücksichtigt werden, ein Konto ergibt sich automatisch, wenn man
die entsprechenden Buchungen betrachtet. Die Buchungen der Benutzer und Services werden nun in
die 4 Teilsysteme der doppelten Buchhaltung wie in Abbildung 3.2.15 gezeigt eingeordnet. Alle
speziellen Buchungen haben die Eigenschaften einer Buchung gemeinsam. Diese sind Nummer des
Gegenkontos, Buchungszeit, Wert und Verwendungszweck. Um festzuhalten, wer die Buchung
veranlasst hat, wird auch der Benutzername des Veranlassers notiert. Daher werden alle speziellen
Buchungen zu einer allgemeinen Klasse Buchung generalisiert.
Wie in [EfBh04] beschrieben untergliedert sich die doppelte Buchhaltung in zwei Arbeitsbereiche.
Zum einen ist der Arbeitsbereich der laufenden Buchungen (während eines Jahres) und zum anderen
ist das der Jahresabschluss, der auf der Bergsportplattform zum Saisonabschluss wird.
Saisonabschluss
Beim Abschluss der Buchhaltung werden alle am Erfolg beteiligten Personen (Autoren,
Autorenbetreuer, Administratoren, Übersetzer, Werber) ausbezahlt. Ein Abschluss soll
vollautomatisch durch einen Administrator durchgeführt werden können. Nachdem die
Bergsportplattform wie in Abschnitt 1.3 beschrieben saisongebunden ist, wird die Buchhaltung
nicht zum Jahresende hin abgeschlossen, sondern 2 Mal pro Jahr, und zwar einmal am Ende der
Sommersaison und einmal am Ende der Winter­ und Frühjahrssaison. Wir sprechen daher nicht von
einem Jahresabschluss, sondern von einem Saisonabschluss.
Nachdem gesetzlich die Buchhaltung jedoch nur am Jahresende abgeschlossen werden darf, müssen
die ausbezahlten Personen ihre Verdienste in ihre eigene Buchhaltung übernehmen, die dann
jahresbasiert arbeiten muss. Das Buchhaltungssystem der Bergsportplattform ist also rechtlich
gesehen nicht offiziell. Das ist jedoch in Ordnung, weil es nur intern arbeitet. Es dient lediglich
dazu, die Einnahmen auf die am Erfolg beteiligten Personen richtig und automatisch aufzuteilen.
Die Ergebnisse, die das Buchhaltungssystem der Bergsportplattform berechnet, müssen daher in die
rechtlich offiziellen Buchhaltungssysteme der ausbezahlten Personen übergeführt werden.
Laufende Buchungen
Laufende Buchungen entstehen entweder durch Aufladung eines Guthabens oder durch den Kauf
einer Dokumentation. Wie in [EfBh04] beschrieben existiert in der doppelten Buchhaltung zu jeder
Buchung eine Gegenbuchung. Nachfolgend wird gezeigt, welche Buchungen und Gegenbuchungen
bei welchem Anlass der laufenden Buchhaltung durchgeführt werden. Dabei wird zwecks
Einfachheit folgende Notation verwendet (der Pfeil deutet den Geldfluss an):
Buchung => Gegenbuchung
Es sei nochmals erwähnt, dass das Buchhaltungssystem der Bergsportplattform kein rechtlich
offizielles ist, es dient nur dazu, alle Käufe, Aufladungen und Verdienste richtig zu verwalten.
Aufladung eines Guthabens
Die Aufladung eines Guthabens bedeutet einen Erlös für die Bergsportplattform. Das Guthaben
Walter Sunk 53

3 Modellierung 30. August 2006
Abbildung 3.2.15: Modellierung der Buchungen im Buchhaltungssystem der Bergsportplattform
wird beim entsprechenden Kunden verbucht. Daher kommt es zu folgenden zwei Buchungen:
Walter Sunk 54

3 Modellierung 30. August 2006
Aufladebuchung => Kundenbuchung
Kauf einer Dokumentation
Beim Kauf einer Dokumentation wird der Kaufpreis der Dokumentation (Tour oder Album) zuerst
als Tourenkaufbuchung oder als Albenkaufbuchung verbucht, wobei der Kaufpreis vom Guthaben
des Kunden in Form einer Kundenbuchung abgezogen wird. Es kommt zu folgenden 2 Buchungen:
Kundenbuchung => Tourenkaufbuchung bzw. Albenkaufbuchung
Nachdem der Autor die Dokumentation direkt an den Kunden verkauft hat, wird dem Autor
nachfolgend der volle Kaufpreis in Form einer Autorenbuchung gutgeschrieben.
Tourenkaufbuchung bzw. Albenkaufbuchung => Autorenbuchung
Nun wird dem Autor von der Bergsportplattform das Autoren­Verkaufsservice (AVS) in Form einer
AVS_Buchung in Rechnung gestellt. Das AVS ist ein Prozentsatz vom Netto­Kaufpreis.
Autorenbuchung => AVS_Buchung
Einen Teil der Kosten des Zahlungsproviders übernimmt die Bergsportplattform, der restliche Teil
ist vom Autor zu übernehmen. Deshalb wird dem Autor ein sogenannter Zahlungsausgleich in
Rechnung gestellt. Das Geld am Zahlungsausgleichskonto wird dazu verwendet, den
Zahlungsprovider zu bezahlen.
Autorenbuchung => Zahlungsausgleichsbuchung
Aus dem Autoren­Verkaufsservice werden nun alle weiteren Dienste beglichen. Eine
Plattformbuchung wird für die Implementierung der Plattform verrechnet. In einer
Autorenbetreuerbuchung wird der Autorenbetreuer des Autors bezahlt. In einer
AIS_Uebersetzungsbuchung werden Übersetzer der Plattform bezahlt. Mit einer Werberbuchung
wird die Provision an den Werber des Kunden abgeführt. Letztendlich wird auch der Teil der
Kosten des Zahlungsproviders, der von der Plattform übernommen wird, verbucht.
AVS_Buchung => Plattformbuchung
=> Autorenbetreuerbuchung
=> AIS_Uebersetzungsbuchung
=> Werberbuchung
=> Zahlungsausgleichsbuchung
Abführung der Umsatzsteuer
Für den Fall, dass die Bergsportplattform umsatzsteuerpflichtig wird, muss jeden Monat die
Umsatzsteuer an das Finanzamt abgeführt werden. Zu diesem Zweck wird die Umsatzsteuer aus
dem Autorenverkaufsservice herausgenommen.
AVS_Buchung => USt_AVS_Buchung
Verbuchung des Saisonabschlusses
Für den Saisonabschluss werden sämtliche Aufwandsbuchungen benötigt. Durch eine
Aufwandsbuchung wird die betreffende Person oder das betreffende Service ausbezahlt. Das Geld
für jede Aufwandsbuchung kommt von der entsprechenden Vermögensbuchung. Es treten also
Buchungen folgender Art auf:
Vermögensbuchung => Aufwandsbuchung
Walter Sunk 55

3 Modellierung 30. August 2006
3.3 Softwarepakete
In diesem Abschnitt werden alle Softwarepakete der Bergsportplattform modelliert.
3.3.1 Grundgerüst der Softwarepakete
Ein jeder Seitenaufruf (Request) eines Benutzers wird durch ein sogenanntes Serverskript
abgearbeitet. Das Serverskript steuert dabei nur die Abarbeitung, führt die Abarbeitung jedoch nicht
selbst durch. Die eigentliche Abarbeitung erfolgt in sogenannten Include­Skripten, die von den
Serverskripten eingebunden werden. Die Serverskripte steuern also die Abarbeitung durch Auswahl
und Einbindung bestimmter Include­Skripte. Abbildung 3.3.1 zeigt den Aufbau der Server­ und
Include­Skripte.
Abbildung 3.3.1: Modellierung der Servers­ und Include­Skripte
Die Serverskripte sind eigenständig und bilden dabei einen bestimmten Server ab. Include­Skripte
hingegen sind Inhalt des zentralen Pakets includes und werden von dort importiert. HTTP­Requests
werden von Skripten im Paket Server­Skripte beantwortet und durch die Einbindung der Pakete
server­includes und common­includes abgearbeitet. Gemäß den in Abschnitt 2.2.3 diskutierten
Sicherheitsaspekten werden sensitive Daten SSL­verschlüsselt übertragen werden. Zu diesem
Zweck werden HTTPS­Requests von Skripten im Paket SSLServer­Skripte beantwortet und durch
die Einbindung der Pakete common­includes und sslserver­includes abgearbeitet. Manche Requests
können sowohl als HTTP­Request als auch als HTTPS­Requests auftreten. Diese Requests werden
von Skripten im Paket SupportServer­Skripte beantwortet und durch die Einbindung des Pakets
common­includes abgearbeitet.
3.3.2 Aufbau eingebundener Softwarepakete
Abbildung 3.3.2 zeigt den Aufbau des Pakets includes, welches gemäß Abschnitt 3.3.1 aus den 3
Paketen server­includes, common­includes und sslserver­includes besteht.
Das Paket server­includes ist für die Abarbeitung von Requests zuständig, die nur über HTTP
gesendet werden. Es besteht intern aus einem Paket, welches für die Präsentation von
Walter Sunk 56

3 Modellierung 30. August 2006
Beispieltouren verantwortlich ist, und aus einem Informationspaket, das für die Präsentation
sämtlicher Informationen über die Bergsportplattform zuständig ist.
Abbildung 3.3.2: Aufbau der eingebundenen Softwarepakete
Gemäß den in Abschnitt 2.2.3 dargestellten Sicherheitüberlegungen werden sensitive Daten stets
SSL­verschlüsselt gesendet. Das Paket sslserver­includes ist für die Abarbeitung von Requests
zuständig, die nur über HTTPS übertragen werden. Nachdem HTTPS­Requests SSL verschlüsselt
sind, ist das Paket sslserver­includes daher für die Registrierung der Benutzer (Paket register), das
Log In (Paket login), das Log Out (Paket logout), die Passwortabfrage (Paket pwrequest), den
Mitgliedsbereich (Paket myhome, siehe auch Abschnitt 3.3.5), das Aufladesystem (Paket aufladen)
und für das Session Management (Paket sessions) verantwortlich sein. Das Paket securecodes stellt
die für die Registrierung und für das Aufladesystem notwendigen Captcha­Tests mit Hilfe von
sogenannten Securecodes zur Verfügung, die Inhalt der Arbeit [WaSu06] sind.
Das Paket common­includes beinhaltet Pakete zur Abarbeitung von Requests, die sowohl als
Walter Sunk 57

3 Modellierung 30. August 2006
HTTP­Requests als auch als HTTPS­Request auftreten können. Nachfolgend werden die
wichtigsten Pakete genauer beschrieben.
• Das Paket bruteforcedefense stellt einen Abwehrmechanismus gegenüber Brute Force
Attacken dar. Wie dieser genau funktioniert ist Inhalt der Praktikumsarbeit [WaSu06] und
kann dort nachgelesen werden.
• Das Paket positionlinks dient dazu, dem Benutzer die momentane Position auf der
Internetseite anzuzeigen und all jene Links zu präsentieren, die zu dieser Position führen. Stellt
man sich die gesamte Internetseite als Baumstruktur vor, dann werden mit Hilfe dieses Paketes
alle Links zu den Knoten des gerade ausgewählten Astes sowie das Blatt angezeigt, auf dem
sich der Benutzer zur Zeit gerade befindet.
• Das Paket layout ist zuständig für den Seitenaufbau einer jeden Seite. Im speziellen baut es die
Hauptnavigation, die Seitennavigation und die Tabs im Hauptfenster auf.
• Das Paket messages dient zur Ausgabe aller möglichen Arten von Meldungen, inklusive
leichter und schwerer Fehlermeldungen.
• Das Paket pdf stellt Funktionen zur Verfügung, durch die PDF­Dokumente generiert werden
können. Es dient dazu, um die PDF­Dokumente der dokumentierten Touren zu generieren.
• Das Paket classes beinhaltet alle verwendeten Klassen.
• Das Paket validate ist für Sicherheitsprüfungen zuständig. Es dient u.a. dazu, dass die
Benutzersprache, Cookies und Sessions überprüft und richtig gesetzt werden.
• Das Paket mail stellt wichtige Funktionen zur Erzeugung von E­Mails zur Verfügung. Dabei
werden insbesondere wichtige Header­Informationen sowie allgemeine Header­ und Footer­
Textzeilen im Body von E­Mails generiert.
• Das Paket tourenmenue ist für die Präsentation des Tourenmenüs und aller darin enthaltenen
Inhalte zuständig. Die genauen Inhalte werden in Abschnitt 3.3.4 beschrieben.
3.3.3 Aufbau der Serverskripte
Gemäß Abschnitt 3.3.1 dienen die Serverskripte dazu, die Abarbeitung von Requests zu steuern.
Die Serverskripte teilen sich dabei in jene Skripte, die nur HTTP­Requests (Paket Server­Skripte)
beantworten, jene, die nur HTTPS­Requests beantworten (Paket SSLServer­Skripte) und jene, die
Requests beantworten, dis sowohl als HTTP­Requests als auch HTTPS­Requests auftreten können
(Paket SupportServer­Skripte). Abbildung 3.3.3 zeigt den Aufbau der Serverskripte.
• Das Paket Server­Skripte ist für die Erzeugung der Beispieltouren (Paket Beispieltouren) und
des Informationsbereichs (Paket Info) zuständig.
• Das Paket SupportServer­Scripte ist für die Erzeugung des Tourenmenüs (Paket
Tourenmenue) und aller darin enthaltenen Inhalte, für die Ausgabe von CSS­Stylesheets
(Paket CSS), für die Generierung von Bildern (Paket IMG) und für die Generierung von Fotos
(Paket Fotoerstellung) zuständig.
• Das Paket SSLServer­Skripte ist für die Steuerung der Aufladung des Guthabens, für die
Steuerung des Log In und des Log Out, für den Mitgliedsbereich (Paket MyHome), für die
Steuerung der Passwortabfrage (Paket PwRequest) und für die Steuerung der Registrierung
von neuen Benutzern zuständig.
Walter Sunk 58

3 Modellierung 30. August 2006
Bei der Serverkonfiguration ist zu beachten, dass der zum Einsatz kommende Webserver so
konfiguriert werden muss, dass bei Auftreten von HTTP und HTTPS­Requests dann auch
tatsächlich die entsprechenden Serverskripte ausgeführt werden.
Abbildung 3.3.3: Aufbau der Serverskripte
3.3.4 Inhalte des Tourenmenüs
Das Paket tourenmenue ist gemäß Abschnitt 3.3.2 Inhalt des Pakets common­includes und wird
daher sowohl für die Abarbeitung von HTTP­Requests als auch für die Abarbeitung von HTTPS­
Requests benötigt. Die Inhalte des Tourenmenüs werden in der Regel über HTTP­Requests
abgefragt, wenn der betreffende Benutzer nicht eingeloggt ist. Im Falle eines eingeloggten
Benutzers werden sämtliche Inhalte des Tourenmenüs über HTTPS abgefragt, weil dann sensitive
Benutzerdaten geschützt werden müssen.
Die einzelnen Inhalte des Pakets tourenmenue sind in Abbildung 3.3.4 dargestellt. Diese bieten
gleichzeitig die Inhalte zur Abarbeitung der Use Cases des Subsystems Tourenmenü der Startseite
(siehe Abschnitt 2.1.1). Demzufolge kommen nachfolgende Pakete zur Anwendung.
• Das Paket touren ist zum einen für die Tourenauswahl und zum anderen für die Darstellung
sämtlicher Dokumentationsinhalte einer Tour zuständig. Zu beachten ist, dass nur immer
solche Inhalte angezeigt werden dürfen, für die der betreffende Benutzer auch die notwendigen
Rechte besitzt.
• Das Paket alben ist zum einen für die Albentypauswahl und die Albenauswahl, und zum
anderen für die Darstellung sämtlicher Dokumentationsinhalte eines Albums zuständig. Da
innerhalb einer Albendokumentation auch Tourendokumentationen angezeigt werden,
importiert das Paket albendoku die entsprechenden Pakete aus dem Paket touren.
Walter Sunk 59

3 Modellierung 30. August 2006
• Das Paket dokusuche ist für die Suche nach Touren und Alben zuständig. Die Ergebnisse der
Suche sind demnach auch nach Touren und Alben gegliedert. Um die Suche durchzuführen,
muss ein Benutzer Schlüsselwörter eingeben, die dann in bestimmten Inhalten aller
vorhandenen und öffentlich freigegebenen Dokumentationen gesucht werden.
• Das Paket neueDokus gibt Auskunft über neue Dokumentationen und bietet die
entsprechenden Links zu diesen Dokumentation an.
3.3.5 Bereich für Mitglieder
Abbildung 3.3.4: Aufbau des Tourenmenüs
Sämtliche Inhalte des Mitgliedsbereich werden durch das in Abschnitt 3.3.2 definierte Paket
myhome erzeugt und verwaltet. Die einzelnen Inhalte des Mitgliedsbereichs zeigt Abbildung 3.3.5.
Die grundlegenden Pakete werden in folgendem kurz beschrieben.
• Die Pakete tourenverwaltung, albenverwaltung und fotoverwaltung sind für das Erstellen und
Verwalten sämtlicher Touren und Alben mit allen zugehörigen Fotos zuständig.
• Die Pakete gekaufteTouren und gekaufteAlben präsentieren gekaufte Dokumentationen.
• Mit Hilfe des Pakets profil können alle Benutzergruppen ihr Profil updaten.
• Das Paket verkauf ist zuständig für die Abwicklung des Kaufs von Dokumentationen.
• Das Paket umsatzanzeige gibt Auskunft über sämtliche Umsätze auf der Plattform.
• Das Paket verwaltung ist zuständig für die administrativen Bereiche der Buchhaltung, der
Verwaltung der Datenbank und der Zuordnung von Werbern zu Kunden.
Walter Sunk 60

3 Modellierung 30. August 2006
Abbildung 3.3.5: Aufbau des Bereichs für Mitglieder
Walter Sunk 61

4 Ausgewählte Bereiche der Implementierung 30. August 2006
4 Ausgewählte Bereiche der Implementierung
In diesem Kapitel werden die wichtigsten Punkte der Implementierung der Bergsportplattform
besprochen. Eine vollständige Implementierung kann jederzeit auf Basis der in Kapitel 3 gezeigten
Modellierung durchgeführt werden. Beginnend mit Abschnitt 4.1 wird die Systemarchitektur der
Plattform besprochen. Es wird gezeigt, welche Systemkomponenten für den Betrieb des Servers
notwendig sind. Abschnitt 4.2 beschäftigt sich dann mit der Umsetzung der Internationalisierung,
also mit der Übersetzung der Plattform. In Abschnitt 4.3 wird letztlich die Fotoverwaltung mitsamt
der Fotogenerierung und der Implementierung der Schutzmaßnahmen für Fotos besprochen.
4.1 Systemarchitektur
Die gesamte Software der Bergsportplattform läuft zur Zeit auf einem Rechner, der an einem
zentralen Access­Point in das Internet eingebunden ist. Abbildung 4.1.1 zeigt in einem
Verteilungsdiagramm sämtliche eigenständige Softwarekomponenten (als Knoten) und Software­
Artefakte, die auf dem Rechner der Plattform laufen. Zusätzlich wird in Abbildung 4.1.1 gezeigt,
welche Aktoren mit welchen Komponenten interagieren.
Abbildung 4.1.1: Softwarekomponenten (Knoten) und Software­Artefakte am Rechner der Plattform
Betriebssystem
Als Betriebssystem wurde Linux gewählt, weil der größte Teil an kostenfreier Open­Source
Software für Linux­Betriebssysteme entwickelt wurde. Es kommt daher nur Open­Source Software
zur Anwendung.
Walter Sunk 62

4 Ausgewählte Bereiche der Implementierung 30. August 2006
Webserver
Als Webserver wurde der Apache Webserver 1 gewählt, weil dieser für seine Stabilität bekannt ist
und sich bereits im internationalen Umfeld in Geschäftsanwendungen bestens bewährt hat. Mit dem
Webserver interagieren sämtliche Benutzer wie in Abschnitt 3.2.1 beschrieben. In den Webserver
wurden nachfolgend beschriebene Module integriert.
Script­Modul PHP
Als Skriptmodul wurde die Skriptsprache PHP 2 verwendet, weil PHP sehr einfach zu verwenden ist
und den kompletten Funktionsumfang, der zur Realisierung der Plattform notwendig ist, zur
Verfügung stellt. In das Script­Modul wurden beim Compilieren zusätzlich eine Crypt­Library und
eine Library zur Internationalisierung integriert.
• Die Crypt­Library wird durch die Library libmcrypt 3 realisiert. Diese Library bietet eine
Vielzahl von Verschlüsselungsmethoden an. Diese Verschlüsselungsmethoden werden
gebraucht, um sensitive Daten sowohl im Datenaustausch als auch zur Ablage in der
Datenbank zu ver­ und entschlüsseln.
• Die Library zur Internationalisierung wird durch die Tools von gettext 4 realisiert. Mit Hilfe
dieser Tools können Projekte sehr effizient wie in Abschnitt 4.2 beschrieben in mehrere
Sprachen übersetzt werden.
SSL­Modul OpenSSL
Wie in Abschnitt 2.2.3 diskutiert soll der Webserver HTTPS­Requests, die SSL verschlüsselt sind,
unterstützen. Aus diesem Grund wurde in den Webserver das SSL­Modul OpenSSL 5 integriert,
welches die notwendige SSL­Verschlüsselung zur Verfügung stellt. Um diese Verschlüsselungsart
verwenden zu können, muss ein SSL­Zertifikat bei einer SSL­Zertifizierungsstelle beantragt
werden. Das SSL­Zertifikat ist dann der öffentliche Ausweis des Servers. Dieser Ausweis ist
notwendig, da Browser in der Regel nur verschlüsselte Verbindungen mit zertifizierten Servern
eingehen. Ist ein Server nicht zertifiziert, dann wird dem Benutzer bei einem Seitenaufruf über
HTTPS im Browser eine Warnung angezeigt, dass der Server nicht vertrauenswürdig ist und aus
Sicherheitsgründen keine Verbindungen aufgebaut werden sollten.
Modul zur Bilderstellung
Dieses Modul ist für die automatische Erstellung sämtlicher Bilder (und damit sämtlicher Fotos)
zuständig, die im Zuge von HTTP­ oder HTTPS­Requests vom Server abgerufen werden. Dieses
Modul wird durch die Library ImageMagick 6 realisiert. Um ein Bild in einer Antwort auf einen
Request zu erzeugen, kommuniziert PHP mit ImageMagick. Wie diese Kommunikation und die
Generierung des Bildes mit ImageMagick im Detail funktionieren, wird in Abschnitt 4.3 gezeigt.
Erstellte Serverskripte
Sämtliche erstellte und in Abschnitt 3.3.1 beschriebenen Serverskripte sowie die zugehörigen
Include­Skripte werden in der Umgebung des Webservers ausgeführt und dienen zur Abarbeitung
1 http://www.apache.org/
2 http://www.php.net/
3 http://mcrypt.sourceforge.net/
4 http://www.gnu.org/software/gettext/
5 http://www.openssl.org/
6 http://www.imagemagick.org/
Walter Sunk 63

4 Ausgewählte Bereiche der Implementierung 30. August 2006
von HTTP­ und HTTPS­Requests.
Server­Software
Außer dem Webserver kommen noch folgende weitere Server zum Einsatz.
FTP Server
Als FTP Server kommt vsftpd 7 zum Einsatz, weil dieser FTP­Server auf Linux­Systemen für seine
Sicherheit und Performance bekannt ist. Der FTP­Server unterstützt TLS­verschlüsselte
Verbindungen. Das TLS­Verschlüsselungsprotokoll ist eine Weiterentwicklung von SSL. Mit Hilfe
von TLS können FTP­Verbindungen und insbesondere der Verbindungsaufbau, im Zuge dessen der
FTP­Client Benutzername und Passwort an den FTP­Server plain­text übertragt, verschlüsselt
werden. Nachdem für SSL ein SSL­Zertifikat benötigt wird, ist ein solches auch für TLS
erforderlich. Der FTP­Server wird benötigt, damit Autoren Ihre Fotos auf den Rechner der
Plattform hinaufladen können. Zu diesem Zweck erhält jeder Autor einen FTP­Account.
Datenbankserver
Als Datenbankserver wird MySQL 8 verwendet, weil MySQL zum einen eine vielfach bewährte
Open­Source Software ist und zum anderen in der verwendeten Version (5.x) bereits alle
notwendigen Technologien (insbesondere Foreign Keys und Stored Procedures) unterstützt. Der
Datanbankserver wird dazu verwendet, alle notwendigen Daten der Bergsportplattform außer Fotos
zu speichern. Nachdem Fotos große Datenmengen darstellen, werden diese im Dateisystem und
nicht in der Datenbank abgelegt. Weil nur der Webserver und Administratoren lokal Verbindungen
zum Datenbankserver aufbauen, werden nur lokale Verbindung (also keine Remote­Verbindungen)
zugelassen, die außerdem durch Passwörter geschützt sind.
Mailserver
Als Mailserver wird sendmail 9 verwendet, weil sendmail ein mittlerweile bewährter Open­Source
Mailserver ist und stets auch im Hinblick auf verbesserte Sicherheitsmaßnahmen weiterentwickelt
wird. Der Nachteil von sendmail ist jedoch, dass der Mailserver aufgrund seines großen
Funktionsumfangs sehr komplex ist. Der Mailserver wird gemeinsam mit dem POP3­Server für die
Abwicklung des E­Mail Verkehrs benötigt. Mitarbeiter sowie Einrichtungen (z.B. der
Kundenservice) der Plattform erhalten eine eigene E­Mail Adresse.
Damit der Mailserver von dritten nicht ausgenützt werden kann, ist für das Versenden von E­Mails
eine Anmeldung (eine SMTP­Authentication) mit Benutzernamen und Passwort am Mailserver
erforderlich. Dafür ist die Einbindung der Library SASL 10 in den Mailserver notwendig. Um
sicherzustellen, dass das Passwort nur verschlüsselt gesendet wird, ist der Mailserver so
konfiguriert, dass eine Anmeldung nur verschlüsselt erfolgen darf. Als Verschlüsselungsmethoden
bei der Anmeldung können in sendmail z.B. CRAM­MD5 oder Kerberos verwendet werden.
Zusätzlich wurde der Mailserver auch so konfiguriert, dass er eine verschlüsselte Übertragung der
E­Mails unterstützt. Dazu kommt wieder das TLS­Verschlüsselungsprotokoll zum Einsatz. Wie
üblich ist für den Einsatz von TLS (TLS ist ja eine Weiterentwicklung von SSL) ein SSL­Zertifikat
notwendig. Nachdem alle diese Konfigurationen ziemlich komplex und umfangreich sind, werden
diese an dieser Stelle nicht näher behandelt. Das Standardwerk für sendmail [SMail03] bietet jedoch
7 http://vsftpd.beasts.org/
8 http://www.mysql.org/
9 http://www.sendmail.org/
10 http://asg.web.cmu.edu/sasl/sasl­library.html
Walter Sunk 64

4 Ausgewählte Bereiche der Implementierung 30. August 2006
ausführliche Informationen.
POP3 Server
Das POP3 Protokoll wird allgemein zum Abholen der E­Mails aus der Mailbox des jeweiligen
Benutzers verwendet. Als POP3­Server, der dieses Protokoll unterstützt, und mit dem daher E­
Mails von der Bergsportplattform abgefragt werden können, wird qpopper 11 verwendet. Dieser
POP3­Server ist auf Linux Betriebssystemen weit verbreitet, relativ einfach zu bedienen und hat
sich schon oftmals bewährt. Außerdem unterstützt dieser POP3­Server verschlüsselte Anmeldungen
(mit Hilfe der Protokolle APOP oder Kerberos) und eine verschlüsselte Datenübertragung über TLS
(wofür wieder ein SSL­Zertifikat benötigt wird). Der POP3­Server wurde so aufgesetzt, dass er
APOP und TLS unterstützt.
SSH­Server
Der SSH­Server ist in der Regel bereits bei Linux­Betriebssystem vorinstalliert und braucht nicht
neu installiert werden. Der SSH­Server wird nur von Administratoren benötigt, die am Rechner
einen eigenen Benutzeraccount haben, um administrative Tätigkeiten (Einspielen neuer Software,
Backups, etc.) am Server durchzuführen. SSH­Verbindungen sind stets automatisch verschlüsselt.
4.2 Internationalisierung ­ Übersetzung der Plattform
Gemäß der Aufgabenstellung in Abschnitt 1.2 wird die Plattform mehrsprachig ausgeführt. Gemäß
Abschnitt 2.2.1 soll die Mehrsprachigkeit dabei nach den Standards für internationalisierte Software
[i18nW3C] implementiert werden. Wie bereits in Abschnitt 4.1 diskutiert werden für die
Internationalisierung die Tools von gettext verwendet. Im folgenden wird gezeigt, wie mit diesen
Tools und zusammen mit der verwendeten Skriptsprache PHP mehrsprachige Software geschrieben
werden kann.
Einbindung von gettext in PHP
Voraussetzung für die Verwendung der Tools von gettext in PHP ist, dass PHP mit gettext­
Unterstützung compiliert wird. Nach der Installation von gettext muss also PHP zuerst mit der
Option „­­with­gettext“ konfiguriert werden.
Funktion gettext() in PHP
Im wesentlichen funktioniert die Übersetzung so, dass der PHP­Funktion gettext() ein Identifier
(eine ID) übergeben wird. Die Funktion gettext() sucht dann diese ID abhängig von der gewählten
Sprache in einer eigenen Sprachdatei und gibt den Text zurück, der zu dieser ID in der Sprachdatei
notiert wurde. Um nun nicht für jede Textausgabe die Funktion gettext() eintippen zu müssen, kann
statt dieser ein Schlüsselwort in Form eines Unterstrichs verwendet werden. Beispielsweise könnte
im Willkommensskript folgender Aufruf geschrieben werden:
echo _('Welcometext');
Nehmen wir an, als Sprache wurde Deutsch gewählt, dann wird nun der String 'Welcometext' in der
deutschen Sprachdatei gesucht (es muss für jede Sprache eine eigene Sprachdatei angelegt werden).
Der zugehörige Eintrag in der deutschen Sprachdatei könnte beispielsweise wie folgt aussehen
(msgid zeigt dabei an, dass der nachfolgende String eine ID ist, msgstr ist der String, welcher zur
vorher definierten ID gehört):
11 http://www.eudora.com/qpopper/
Walter Sunk 65

4 Ausgewählte Bereiche der Implementierung 30. August 2006
msgid "Welcometext"
msgstr "Willkommen auf unserer Internetseite!"
In diesem Fall liefert die Funktion _('Welcometext') also den String „Willkommen auf
unserer Internetseite!“ zurück, der dann durch die echo Funktion ausgegeben wird.
Erstellen der Sprachdateien
Die Tools von gettext stellen das Programm xgettext zur Verfügung, das IDs aus Sourcecode­
Dateien automatisch extrahiert und in einer Sprachdatei ablegt. Eine Sprachdatei ist dabei lediglich
eine Textdatei mit der Dateiendung .po. Die extrahierten IDs werden in der Sprachdatei zeilenweise
gespeichert. Eine Übersetzung muss unterhalb der jeweiligen ID wie im obigen Beispiel notiert
werden.
Um beispielsweise die IDs aus den Dateien index.php und welcome.php in die Sprachdatei
server.po zu extrahieren, kann folgender Funktionsaufruf verwendet werden (in diesem Beispiel
wird angenommen, dass die Source­Dateien im Format des westeuropäischen Zeichensatzes ISO­
8859­1 gespeichert sind):
xgettext -L PHP -o server.po –keyword=_ \
--from-code=ISO-8859-1 \
index.php welcome.php
Verzeichnisstruktur der Sprachdateien
Um die Effizienz bei der Auffindung der IDs in einer Sprachdatei zu steigern, werden Sprachdateien
kompiliert. Eine kompilierte Sprachdatei hat die Dateiendung .mo. Die kompilierten Dateien
müssen dann in eine teils vordefinierte Verzeichnisstruktur kopiert werden. Nehmen wir an, wir
möchten deutsche, englische und französische Inhalte auf der Internetseite ausgeben. In unserem
begonnenen Beispiel brauchen wir in diesem Fall 3 Versionen der Sprachdatei server.po. Durch
Kompilieren erhalten wir 3 server.mo Dateien. Nehmen wir überdies an, dass wir als Basis­
Verzeichnis für kompilierte Sprachdateien das Verzeichnis
/www/projects/tours/locale/
verwenden möchten. Dann muss folgende Verzeichnisstruktur aufgebaut werden, wobei die 3
kompilierten server.mo Dateien wie folgt abzulegen sind.
/www/projects/tours/locale/de_DE/LC_MESSAGES/server.mo
/www/projects/tours/locale/en_GB/LC_MESSAGES/server.mo
/www/projects/tours/locale/fr_FR/LC_MESSAGES/server.mo
Die vordefinierte Verzeichnisstruktur besteht dabei aus den sogenannten Locals (in unserem Fall
also aus den drei Locals de_DE, en_GB, fr_FR) und den Verzeichnissen LC_MESSAGES. Die
Locals sind dabei in der Datei
/usr/share/locale/locale.alias
definiert. Gegebenenfalls müssen in dieser Datei Definitionen für Sprachen ergänzt werden.
Kompilieren der Sprachdateien
Um eine .po­Datei in eine .mo­Datei zu kompilieren, bieten die Tools von gettext das Programm
mgsfmt an. Um z.B. die deutsche Version unserer server.po Datei in das richtige Verzeichnis zu
kompilieren, wird folgender Programmaufruf verwendet:
Walter Sunk 66

4 Ausgewählte Bereiche der Implementierung 30. August 2006
msgfmt \
-o /www/projects/tours/locale/de_DE/LC_MESSAGES/server.mo \
server.po
Textdomain
Nun muss nur noch im PHP­Skript der Funktion gettext() mitgeteilt werden, wo sich die
entsprechende Sprachdatei befindet. Dies geschieht durch Definition der entsprechenden
Textdomain. Nehmen wir an, wir möchten Deutsch als Sprache, dann wird in unserem Beispiel eine
Ausgabe wie folgt durchgeführt:
$lang = "de_DE";
$binding = "/www/projects/tours/locale/";
$domain = "server";
setlocale(LC_MESSAGES, $lang.".iso-8859-1");
bindtextdomain($domain, $binding);
textdomain($domain);
bind_textdomain_codeset($domain, 'iso-8859-1');
echo _('Welcometext');
Der Variable $lang muss das entsprechende Locale, der Variable $binding das entsprechende Basis­
Verzeichnis und der Variable $domain der Dateiname der Sprachdatei ohne Erweiterung
zugewiesen werden.
4.3 Fotoverwaltung
Verwaltung der Fotos
Gemäß Abschnitt 3.1.2 werden in Tourendokumentationen kleine Fotos in Form der Fotogalerie,
mittelgroße Fotos in Form von Einzelfotos und Originalfotos angezeigt. Alle drei Formen der
Darstellung benötigen unterschiedliche Pixel­Abmessungen der Fotos. Autoren laden beim
Dokumentieren der Tour Originalfotos über FTP (siehe Abschnitt 4.1) auf den Server. Um nicht bei
jeder Anzeige von Einzelfotos und der Fotogalerie die Originalfotos komprimieren zu müssen,
werden Fotos in folgenden Pixel­Abmessungen gespeichert:
• kleine Fotos: 180x135 Pixel
• mittelgroße Fotos: 580x435 Pixel
• Originalfotos: 1600x1200 Pixel
Für jede Tour wird ein eigenes Verzeichnis angelegt, in der sämtlichen Daten, die zur Tour gehören
und nicht in der Datenbank gespeichert sind, abgelegt werden. Fotos werden daher in
Unterverzeichnissen des jeweiligen Verzeichnisses der zugehörigen Tour gespeichert.
Laden von Fotos
Aus Sicherheitsgründen ist es wichtig, dass die Verzeichnisse der Touren nicht im Webserver­
Verzeichnisbaum liegen, da sonst über HTTP­Requests auf die Fotos unerlaubt zugegriffen werden
könnte. Damit ein Tourenfoto überhaupt erst geladen wird, muss zuerst die Berechtigung des
Benutzers überprüft werden. Tourenfotos müssen daher von PHP­Skripten geladen werden. Das
PHP­Skript muss zuerst die Berechtigung des jeweiligen Benutzers prüfen, danach erst darf das
PHP­Skript das Foto laden und senden. Das Laden von Fotos mit PHP kann in der Dokumentation
Walter Sunk 67

4 Ausgewählte Bereiche der Implementierung 30. August 2006
von PHP nachgelesen werden.
Cachen von Fotos
Gemäß Abschnitt 2.2.3 soll Browsern mitgeteilt werden, Fotos zu cachen, um die zur Verfügung
stehende Bandbreite nicht unnötig zu verbrauchen. Zu diesem Zweck wird die Header­Information
"If­Modified­Since" ausgewertet, die der Browser beim Request nach dem Foto an den Server
sendet. Der Browser zeigt damit an, wann das Foto in seinem Cache zum letzten Mal verändert
wurde. Wie in Abschnitt 3.2.3 beschrieben, wird die Information, wann das Foto zum letzten Mal
geändert oder upgedated wurde, zu jedem Foto gespeichert. Aufgrund dessen kann entschieden
werden, ob das Foto neu geladen werden muss oder vom Cache des Browsers geladen werden kann.
Für den Fall, dass das Foto nicht upgedated oder geändert wurde und daher vom Cache des
Browsers geladen werden kann, muss dem Browser als Header die Antwort "304 Not Modified"
gesendet werden. Folgendes Beispiel zeigt die Implementierung in PHP, wobei angenommen wird,
dass die Variable $lm die Zeit des letzten Updates des Fotos beinhaltet.
$headers = apache_request_headers();
if (isset($headers['If-Modified-Since'])
&& (strtotime($headers['If-Modified-Since']) >= $lm)) {
$str = 'Last-Modified: '.gmdate('D, d M Y H:i:s', $lm).' GMT';
// Photo not modified => send '304 Not Modified'
header($str, true, 304);
exit();
}
Muss ein Foto neu geladen werden, dann muss dem Browser mitgeteilt werden, das Foto zu cachen.
Im weiteren muss dem Browser mitgeteilt werden, wann das Foto zum letzten Mal geändert wurde.
Das ist notwendig, damit der Browser den Header 'If­Modified­Since' in weiteren Requests
mitsendet und diese Information dann wie in obigem Beispiel gezeigt ausgewertet werden kann.
Durch folgende gesendete Header­Informationen wird der Browser richtig informiert (wieder unter
der Annahme, dass die Variable $lm die Zeit des letzten Updates des Fotos beinhaltet).
$str = 'Last-Modified: '.gmdate('D, d M Y H:i:s', $lm).' GMT';
header("Cache-Control: cache");
header("Pragma: cache");
header($str, true, 200); // 200 means OK
Verwendung der Library ImageMagick
Bilderstellung in PHP mit Hilfe von ImageMagick
Wie in Abschnitt 4.1 gezeigt wird zur Bilderstellung die Library ImageMagick verwendet. Bilder
werden in Folge eines HTTP­ oder HTTPS­Requests durch ein PHP­Script geladen, wobei intern im
PHP­Script das Bild zuerst mit Hilfe von ImageMagick erzeugt wird. Um das Bild mit
ImageMagick zu erzeugen, muss in PHP eine Pipe zu ImageMagick geöffnet und über diese Pipe
der notwendige ImageMagick­Programmaufruf zum Erstellen des Bildes ausgeführt werden. Das
erstellte Bild wird dann von PHP über diese Pipe eingelesen und anschließend gesendet. In der
Implementierung sieht dies wie folgt aus (unter der Annahme, dass die Variable $cmd den
ImageMagick­Programmaufruf beinhaltet).
$handle = popen($cmd,"rb"); // open pipe, execute ImageMagick-command
$contents = stream_get_contents($handle); // read image from pipe
pclose($handle); // close pipe
sendHeaders(); // send necessary image-headers
print $contents; // send image
Walter Sunk 68

4 Ausgewählte Bereiche der Implementierung 30. August 2006
Für PHP existiert eine Erweiterung, die einfache Funktionen zur Bilderstellung mit ImageMagick
zur Verfügung stellt. Dabei kommt der Entwickler mit ImageMagick nicht in Berührung und
verwendet lediglich die Funktionen der Erweiterung. Diese Erweiterung nennt sich imagick 12 .
Nachteil beim Verwenden der Erweiterung ist jedoch, dass nur der relativ geringe Funktionsumfang
der Erweiterung und nicht der komplette Funktionsumfang von ImageMagick zur Verfügung steht.
Außerdem ist die Qualität (speziell bei Annotierung) der erstellten Bilder bei der direkten Erstellung
über die Pipe um einiges besser als bei Erstellung der Bilder mit den Funktionen der Erweiterung.
Aus diesen Gründen wurde in dieser Arbeit die direkte Erstellung bevorzugt.
Komprimieren von Fotos
Wie in diesem Abschnitt gezeigt werden Fotos in 3 verschiedenen Formaten gespeichert, wobei
Autoren die Originalfotos zur Verfügung stellen. Die kleinen und mittelgroßen Fotos werden durch
Komprimieren der Originalfotos erzeugt. Außerdem kann es vorkommen, dass Originalfotos, die
der Autor zur Verfügung stellt, ebenfalls zu groß sind und komprimiert werden müssen. Eine
Komprimierung von Fotos kann mit dem Programm convert der ImageMagick Library wie folgt
vorgenommen werden (mit dem Parameter resize werden die neuen Abmessungen angegeben,
in.JPG ist das zu komprimierende Foto, dieses wird nach out.JPG komprimiert).
Fotoschutz
convert -resize 180x135 in.JPG out.JPG
Gemäß Abschnitt 2.2.3 sollen Fotos durch Beschreiben der Header­Tags, Annotierung,
Wasserzeichen und Steganographie geschützt werden. Im folgenden wird gezeigt, wie diese
Schutzmaßnahmen mit der Library ImageMagick durchgeführt werden können. Weitere gute
Beispiele finden sich unter [IMagick].
Beschreiben der Header­Tags: Beispielsweise existiert für jedes Bild der Header­Tag „comment“.
Dieser eignet sich insbesondere für Copyright­Einträge. Das Programm mogrify der ImageMagick
Library führt Änderungen am Bild selbst durch. Folgender Programmaufruf fügt den Copyright­
Vermerk „(c) Walter Sunk“ zum Bild image.JPG als Kommentar hinzu.
mogrify -comment "(c) Walter Sunk" image.JPG
Um zu überprüfen, ob der Header­Tag auch wirklich beschrieben wurde, kann das Programm
identify der ImageMagick­Library wie folgt verwendet werden (der Parameter verbose sorgt für
eine detaillierte Ausgabe der Informationen).
identify -verbose image.JPG
Annotierung : Es gibt eine Vielzahl an Formen der Annotierung, also dem Hinzufügen von Text in
ein Bild, deshalb sei hier nur ein einführendes Beispiel gegeben. Ausführliche Beispiele finden sich
auf [IMagick] verwiesen. Das Ergebnis des folgenden Programmaufrufs zeigt Abbildung 4.3.1.
12 http://pecl.php.net/package/imagick
Abbildung 4.3.1: Ein Foto vor (links) und nach der Annotierung (rechts)
Walter Sunk 69

4 Ausgewählte Bereiche der Implementierung 30. August 2006
convert -pointsize 24 -fill white \
-draw "text 5,132 '(c) Walter Sunk'" in.JPG out.JPG
Wasserzeichen: Für das Erstellen von Fotos mit Wasserzeichen muss zunächst das Wasserzeichen
als graues Bild ohne Hintergrund vorliegen. Danach kann dann das Programm composite der
ImageMagick Library zur Erstellung des Wasserzeichens verwendet werden. Das Ergebnis des
folgenden Programmaufrufs zeigt Abbildung 4.3.2.
composite -dissolve 35% -gravity southeast -geometry +2+1 \
watermark.JPG in.JPG out.JPG
Abbildung 4.3.2: Foto ohne Wasserzeichen (links), das Wasserzeichen (Mitte), Foto mit Wasserzeichen (rechts)
Steganographie: Um ein kleines Foto in einem großen Foto zu verstecken, kann ebenfalls das
Programm composite der ImageMagick Library verwendet werden. Zum Verstecken wird ein Offset
benötigt, der geheim gehalten wird. Folgender Programmaufruf versteckt das Bild hide.PNG (dieses
sollte im png­Format vorliegen) im Bild in.JPG und schreibt das Ergebnis in das Bild out.PNG.
composite -stegano 53 hide.PNG in.JPG out.PNG
Um nun das versteckte Bild wieder herauszubekommen, bestimmt man zuerst die Größe des Bildes
hide.png wie folgt:
identify hide.PNG
Als Output erhält man dann eine ähnliche Zeile wie folgende:
hide.PNG PNG 215x13+0+0 DirectClass 8-bit 3.4kb 0.000u 0:01
Um nun das versteckte Bild anzuzeigen, braucht man den geheimen Offset und die Abmessungen
des versteckten Bildes. Zur Anzeige kann das Programm display der ImageMagick Library wie
folgt verwendet werden:
display -size 215x13+53 stegano:out.PNG
Um nun Fotos zu schützen, erstellt man zuerst mit ImageMagick ein Bild hide.PNG, das den
Benutzernamen des Benutzers zeigt, und versteckt dieses in allen Bildern, die der Benutzer von der
Internetseite herunterladet.
Walter Sunk 70

5 Benutzungstests 30. August 2006
5 Benutzungstests
Um zu sehen, wo Benutzer beim Anwenden der Internetseite Probleme haben, wurden ca. 40
Benutzungstests mit unterschiedlich erfahrenen Internetbenutzern durchgeführt. Aus Zeitgründen
waren leider nicht mehr Tests möglich. Die Ursachen für diese Benutzungsprobleme wurden nach
bester Möglichkeit beseitigt. In Abschnitt 5.1 wird zunächst auf allgemeine Benutzungsprobleme
eingegangen, mit denen vermutlich jede Internetseite umzugehen hat. Abschnitt 5.2 zeigt dann
spezielle Probleme und deren Beseitigung, die insbesondere mit dem Inhalt der Internetseite zu tun
haben. Um Probleme im allgemeinen eher zu vermeiden, bietet sich ein möglichst einfaches
Benutzer­Interface an, das jedoch in der Regel Sicherheitsprobleme mit sich bringt. Um dies zu
zeigen werden in Abschnitt 5.3 ausgewählte Gegensätze zwischen Benutzerfreundlichkeit und
Internet Security gemäß [InetSec] diskutiert.
5.1 Allgemeine Benutzungsprobleme
In diesem Abschnitt werden Benutzungsprobleme beschrieben, die möglicherweise für jeden
Herausgeber einer Internetseite von Interesse sind.
Benutzer lesen nicht
Bei den Tests hat sich als schwierigstes Problem im Benutzer­Interface herausgestellt, dass
Benutzer aus Zeitgründen nicht lesen, sondern lediglich nur wahrnehmen. Oftmals ist jedoch ein
Mindestmaß an Text erforderlich, um Inhalte von Seiten oder Abläufe von Interaktionen zu
erklären. Z.B. ist es schwer, zu erklären, wie das Zahlungssystem funktioniert, wenn der Benutzer
nicht bereit ist, ein paar Zeilen Text zu lesen. Im Idealfall sollte also die Seite daher so aufgebaut
sein, dass der Benutzer bereits am Layout der Seite erkennt, was zu tun ist, ohne viel Text lesen zu
müssen. Das ist jedoch in der Praxis nicht wirklich einfach.
Englische Ausdrücke oder Fachausdrücke
Einige der Benutzer hatten Probleme mit englischen Ausdrücken, wie z.B. mit „Account“ oder
„Home“ (die Begriffe wurden geändert zu „Benutzerkonto“ und „Startseite“, das war dann bei
nachfolgenden Tests besser). Es gab auch Probleme mit dem Wort „Registrierung“ bei unerfahrenen
Internetbenutzern. Große Seiten verwenden oft das Wort „Anmeldung“ anstelle von
„Registrierung“. Die Verwendung des Wortes „Anmeldung“ war besser. Generell hatten
unerfahrenere Internetbenutzer mit englischen Ausdrücken mehr Probleme. Übersetzt man einen
englischen Begriff ins Deutsche, dann muss man darauf achten, erfahrene Internetbenutzer mit dem
deutschen Begriff nicht zu verwirren, die sich vielleicht den englischen Begriff erwarten würden.
Passwörter
Kennt man den Benutzernamen eines Benutzers, dann beruht in der Regel die gesamte Sicherheit
zum Schutz des Benutzeraccounts auf dem Passwort des Benutzers. Am einfachsten kann ein
Passwortschutz dadurch angegriffen werden, dass ein Angreifer Passwörter bei der Passworteingabe
ausprobiert. Viele Benutzer verwenden beispielsweise ihren Vornamen oft als Passwort. Derartige
Passwörter sind sehr einfach zu erraten. Wie in [WaSu06] beschrieben, sollten Passwörter
zumindest einen Großbuchstaben, einen Kleinbuchstaben und eine Zahl beinhalten. Auf der
Plattform werden daher Passwörter mit diesen Kriterien verlangt. Nachdem viele Benutzer am Ende
eines Passwortes oft als einzige Zahl eine „1“ angeben, wird auch die Zahl „1“ am Ende eines
Passwortes aus Sicherheitsgründen nicht erlaubt.
Walter Sunk 71

5 Benutzungstests 30. August 2006
Bei fast allen Benutzungstests hat sich jedoch herausgestellt, dass Benutzer extrem verärgert sind,
Passwörter mit mindestens einem Groß­, einem Kleinbuchstaben und einer Zahl verwenden zu
müssen. Der Hauptgrund war, dass man sich ein derartiges Passwort nicht merken könne, es extra
irgendwo speichern und bei jedem Gebrauch nachsehen müsse. Es kam auch oft die Frage, warum
das überhaupt notwendig ist, ein so kompliziertes Passwort zu verlangen. Es besteht hier also
offenbar kein Sicherheitsdenken bei vielen Benutzern. Mit dem Benutzerhinweis bei der
Passworteingbe, dass das Passwort zur Sicherheit der Website diene, wurden bei weiteren Tests
derartige Passwörter besser akzeptiert.
Es hängt also vom Sicherheitsdenken des jeweiligen Herausgebers einer Internetseite ab, welche
Form von Passwörtern verwendet wird. Sollte man Bedingungen an ein Passwort stellen, dann muss
man sich überlegen, wie man diese Bedingungen einem Benutzer am besten (und am schonendsten
für dessen Nerven) mitteilt. Ein nicht zu unterschätzendes Problem ist, dass Benutzer nicht lesen.
Schreibt man also Bedingungen für ein Passwort in Textform hin, dann muss man damit rechnen,
dass diese Bedingungen vorerst nicht gelesen werden und der Benutzer unweigerlich ein Passwort
eingibt, dass nicht akzeptiert wird. Das resultiert in einem Fehler, der den Benutzer wieder ziemlich
verärgern kann.
Back­Links
Es gab Benutzer, die eine Internetseite zuerst einmal von vorne bis hinten durchklicken, um so den
Aufbau der Seite kennen zu lernen. Für derartige Benutzer ist es extrem wichtig, immer zum
vorigen Schritt zurück kommen zu können. Ist eine Rückkehr zum vorigen Schritt nicht möglich,
dann werden diese Benutzer verwirrt und somit verärgert und gehen vielleicht von der Seite weg.
Um dies zu verhindern, sollte man Back­Links anbringen, die immer zum vorigen Schritt zurück
verweisen. Bei Internetseiten mit einer Baumstruktur könnte es für derartige Benutzer hilfreich sein,
alle Knoten des momentanen Astes stets als Linkfolge angezeigt zu bekommen. Oft bieten sich auch
sogenannte Sitemaps an, in denen der gesamte Seiteninhalt in übersichtlicher Form mitsamt der
zugrunde liegenden Struktur dargestellt sind.
Automatische E­Mails mit Links
Oft werden E­Mails mit einem Link als Inhalt an Benutzer geschickt, wobei der Link in der E­Mail
ausgeführt werden muss. Speziell für unerfahrene Benutzer kann die Ausführung eines Links in
einer E­Mail ein nicht zu überwindendes Problem darstellen. Benutzer sind es in der Regel
gewöhnt, auf einen Link klicken zu können. Es kann jedoch vorkommen, dass Links in einer E­Mail
nicht so dargestellt werden, dass der Benutzer zum Ausführen des Links nur daraufklicken braucht.
Oft kommt es vor, dass E­Mail Inhalte im Plaintext dargestellt werden. In solchen Fällen muss der
Benutzer selbst aktiv werden, und beispielsweise den Link in die Adresszeile seines Browser
kopieren und dann selbst ausführen.
Die Frage ist nun, welchen Text man zusätzlich zu einem Link in die E­Mail schreibt, um dem
Benutzer das Vorgehen zur Ausführung des Links mit allen auftretenden Möglichkeiten klar zu
machen. Nehmen wir als Beispiel die Registrierung eines Benutzers. Am Ende der Registrierung
wird dem Benutzer ein Link geschickt, durch dessen Ausführung der Account des Benutzers
aktiviert wird. Im folgenden wird demonstriert, mit welcher Vielfalt an Benutzern gerechnet werden
muss. Folgender Ansatz konnte von ca. einem Drittel der Testpersonen nicht überwunden werden:
Um Ihren Account zu aktivieren, führen Sie bitte nachfolgenden Link aus: ...
Dieser Text hat zwei Probleme: entweder kamen Benutzer mit dem Wort „Account“ nicht zurecht
Walter Sunk 72

5 Benutzungstests 30. August 2006
oder sie wussten nicht, was unter der Phrase „Link ausführen“ zu verstehen war. Folgender zweiter
Ansatz war zumindest besser, hatte aber das Problem, dass Links eben nicht immer so dargestellt
werden, dass man nur daraufklicken braucht.
Um Ihren Zugang zum Mitgliedsbereich zu aktivieren, klicken Sie bitte auf nachfolgenden Link: ...
Circa 75% (!) der Benutzer sind gescheitert, wenn der Link anders als durch Anklicken auszuführen
war. Aus Sicht der Benutzerfreundlichkeit ist dieser Ansatz also sehr bedenklich.
Obwohl man es kaum für möglich halten sollte, kamen auch 3 Benutzer mit folgendem Text nicht
zurecht, obwohl die Links vom E­Mail Programm als ausführbar angezeigt wurden.
Um Ihren Zugang zum Mitgliedsbereich zu aktivieren, klicken Sie bitte auf nachfolgenden Link:
http://www.AlpinImageS.com/anmelden/aktivierung.php?RegID=27bd35...
Viel Spaß auf www.AlpinImageS.com!
Es passierte, dass 3 Benutzer tatsächlich auf den zweiten Link, auf www.AlpinImageS.com und
nicht auf den ersten Link klickten. Nachdem Sie sich dann auch klarerweise nicht einloggen
konnten, haben sie gemeint, sie würden die Seite nun verlassen. Daraus kann geschlossen werden,
dass die E­Mail nachfolgend keinen Link beinhalten darf, der verwechselt werden könnte.
Um nun auch Benutzer zu unterstützen, bei denen Links nicht als ausführbar angezeigt werden,
wurde folgender Text ausprobiert:
Um Ihren Zugang zum Mitgliedsbereich zu aktivieren, klicken Sie bitte auf nachfolgenden Link.
Sollte der Link nicht funktionieren, dann kopieren Sie den Link bitte in die Adresszeile Ihres
Browsers. ...
Folgende Probleme traten auf: 2 Benutzer waren nicht in der Lage, den Link zu kopieren. Eine
Person, die es zwar schaffte, den Link zu kopieren, hat diesen dann im Browser nicht ausgeführt,
weil im Text nicht steht: „Bitte drücken Sie nachher die Eingabetaste“. Alle 3 Personen schafften
es also nicht, sich erfolgreich zu registrieren.
Jenen Benutzern, die nicht wissen, wie man Text kopiert, kann mit einem zusätzlichen Code
geholfen werden, der dann auf einer einfach zu erreichenden Internetadresse eingeben werden muss.
Manche große Internetseiten verwenden beispielsweise den folgenden Text unterhalb des
Aktivierungslinks, wenn der Benutzer nicht mit dem Link zurecht kommt.
Sollten Sie immer noch Probleme mit dem Link haben, dann gehen Sie bitte auf die Seite
http://www.xxx.com/checknumbers/
und geben Sie dort folgenden Code ein: 8dhzen7j
In diesem Fall geht man davon aus, dass der Benutzer in der Lage ist, selbstständig einen neuen
Browser zu öffnen, danach die (relativ einfach aussehende und möglichst kurze) Internetdresse
http://www.xxx.com/checknumbers/ in die Adresszeile einzugeben, diese auszuführen und auf der
erscheinenden Seite den Code 8dhzen7j einzugeben. Dieses Vorgehen wird bereits von ein paar
großen Internetseiten unterstützt. Auf [AIS] wurde diese Vorgehen aus Zeitgründen noch nicht
realisiert. Eine zukünftige Implementierung ist jedoch bereits vorgemerkt.
Interaktionen mit mehreren Schritten
Bei den Benutzungstests wurde festgestellt, dass die Versuchspersonen Interaktionen mit weniger
Schritten (bei denen in jedem Schritt mehr einzugeben ist), gegenüber Interaktionen mit mehreren
Schritten (bei denen in jedem Schritt nur wenig einzugeben ist), den Vorzug geben. Dies war
deshalb der Fall, weil Interaktionen mit weniger Schritten für die Benutzer einen weniger
Walter Sunk 73

5 Benutzungstests 30. August 2006
komplexen Eindruck machten. Demnach wurde z.B. ein großes Formular bei der Registrierung
gegenüber mehreren kleinen Formularen bevorzugt. Bei Verwendung eines großen Formulars kam
es jedoch zu dem Problem, dass Anmerkungen zu Eingabefeldern praktisch nicht mehr gelesen
wurden, weil das Formular aufgrund seiner Größe bereits zu viel Text beinhaltete. Eingabedaten mit
besonders wichtigen textlichen Anmerkungen wurden daher in eigene Schritte herausgezogen.
Generell ist bei Interaktionen mit mehreren Schritten darauf zu achten, dass der Benutzer zurück
gehen kann, um seine Daten zu ändern. Am Ende einer Interaktion sollten dem Benutzer nochmals
seine Daten angezeigt werden, damit die Daten im Fehlerfall geändert werden können (was
natürlich voraussetzt, dass die Daten auch geändert werden können). Ein berühmtes Beispiel für
eine Interaktion mit mehreren Schritten, bei der ein Zurückgehen des Benutzers Fehler verursachte,
war der sogenannte Amazon Bug. Durch das Zurückgehen konnte der Fall eintreten, dass unerwartet
ältere Versionen der Produktliste gekauft wurden. In [AmBug02] werden beispielsweise
Möglichkeiten aufgezeigt, wie Fehler im Falle des Amazon Bugs vermieden werden können.
Verwendung von Captchas
Gemäß [CMU] sind Captchas kleine Tests, die Menschen in der Regel bestehen, Computer jedoch
nicht. Dadurch kann bestimmt werden, ob eine Anfrage von einem Computer oder einem Menschen
kommt. Wie in [WaSu06] gezeigt, werden Captchas oft dazu verwendet, um Interaktionen (z.B.
eine Registrierung) vor der automatisierten Zugriffen durch Computer zu schützen. Bei der
Registrierung und im Zahlungssystem des Projekts [AIS] werden ebenfalls Captchas verwendet.
Der Test besteht in diesem Fall darin, dass ein Benutzer eine Zeichenfolge aus einem Bild auslesen
und diese eingeben muss, nur dann kann der Benutzer fortfahren. Abbildung 5.1.1 zeigt ein
einfaches Captcha in Bildform.
Abbildung 5.1.1: ein Captcha
Wie in [WaSu06] beschrieben ist die Wahrscheinlichkeit, dass ein Computer diesen Test besteht,
umso geringer, umso unkenntlicher und umso besser versteckt die Buchstaben in dem Bild sind.
Genau das ist das Problem bei der Anwendung. Umso unkenntlicher die Buchstaben sind, umso
größer ist die Wahrscheinlichkeit, dass selbst ein Mensch den Test nicht besteht. Ist dies der Fall
kann ein Benutzer ziemlich verärgert werden, insbesondere dann, wenn er den Test mehrere Male
hintereinander nicht besteht. Es kann dazu kommen, dass der Benutzer nicht weitermacht, die Seite
verlässt und aufgrund des Ärgers nicht mehr zurückkommt.
Bei den durchgeführten Benutzertests hat sich herausgestellt, dass oft der Sinn von Captchas (die
Abwehr von automatisierten Computerzugriffen) nicht verstanden wird, und Captchas dadurch als
lästig und unangenehm empfunden werden. Folgende Probleme traten bei der Verwendung auf:
• Das Captcha war zu lange. Es wurden anfangs 8 ­10 Zeichen verwendet. Dies führte zu vielen
Eingabefehlern der Benutzer. Ab 6 Zeichen gab es in der Regel keine Probleme.
• Das Captcha hat zwischen Groß­ und Kleinschreibung unterschieden. Benutzer waren
verärgert, als das Catpcha aufgrund derartiger Eingabefehler wiederholt werden musste.
• Die Buchstaben waren nicht genau erkenntlich. Es wurde anfangs eine Schriftart mit verzierten
Buchstaben verwendet, wodurch manche Buchstaben nicht gut genug erkannt werden konnten.
• Manche Buchstaben wurden verwechselt. Typisch ist das z.B. für die Null „0“ und für „O“ wie
Otto. Derartige Verwechslungsmöglichkeiten müssen ausgeschlossen werden.
Walter Sunk 74

5 Benutzungstests 30. August 2006
Zahlungssystem
Das Hauptproblem des Zahlungssystems war, dass Benutzer dieses gänzlich verstehen wollten,
ohne Text zu lesen. War auch nur ein Detail unklar, wurde das betreffende Zahlungssystem nicht
verwendet. Bei Zahlungssystemen muss also besonders auf die Benutzerfreundlichkeit Wert gelegt
werden, sonst werden sie nicht verwendet und der Kunde kauft nicht, obwohl er schon kaufen
wollte. Allgemein gesprochen kamen Benutzer, die bereits Erfahrung mit Online­Käufen hatten,
besser zurecht als Benutzer, die noch nie im Internet eingekauft haben. Das Hauptproblem bestand
also darin, einem Benutzer übersichtlich und kurz klar zu machen, wie die entsprechende
Zahlungsmethode funktioniert. Die Realisierung der einzelnen Zahlungsmethoden ist Inhalt der
Arbeit [WaSu06]. Die Probleme, die sich mit den einzelnen Zahlungsmethoden ergeben haben
werden daher an dieser Stelle nicht behandelt und können in [WaSu06] nachgelesen werden.
5.2 Spezielle Benutzungsprobleme auf der realisierten Internetseite
Beispieltouren
Sämtliche Benutzer wollten klarerweise wissen, was sie kaufen, bevor sie kaufen. Aus diesem
Grund werden öffentlich zugängliche Beispieltouren angeboten. Die Beispieltouren umfassen dabei
genau dasselbe Angebot wie eine erwerbbare Tour. Das Hauptproblem bei Verwendung der
Beispieltouren war, Benutzer, die zum ersten Mal auf die Seite kamen, zuerst zu den Beispieltouren
hinzuführen. Hier wurden unterschiedlichste Tests unternommen. Folgende Maßnahmen wurden
getroffen, um Erstbesucher zu den Beispieltouren hinzuführen.
• Der Link zu den Beispieltouren wurde auf der Startseite angebracht.
• Der Link wurde optisch auffällig markiert.
• Der Link wurde textlich als Link für Erstbesucher beschrieben.
• Die Beispieltouren wurden als kostenfrei angegeben.
• Die Links auf der Startseite wurden auf ein Minimum reduziert.
Bei den nachfolgenden Tests haben Benutzer dann auch wirklich die Beispieltouren sofort gefunden
und mit diesen begonnen.
Passwortabfrage
Wie in Abschnitt 2.2.3 beschrieben wird es aus Sicherheitsgründen nicht zugelassen, dass Benutzer
ihr Passwort ändern. Zu diesem Zweck erhalten Benutzer einen Kontoschlüssel, mit dem sie ihr
Passwort abfragen können, sollten sie es vergessen haben. Bei der Passwortabfrage ist daher wie in
Abschnitt 3.1.7 beschrieben der Kontoschlüssel notwendig. Der Kontoschlüssel dient dabei auch
wirklich als Schlüssel einer Verschlüsselungsmethode zum Entschlüsseln des Passwortes.
Einer der größten anfänglichen Fehler war, diesen Schlüssel nicht Kontoschlüssel, sondern
Passwortschlüssel zu nennen. Dies hatte zur Folge, dass einige Benutzer den Schlüssel mit ihrem
Passwort vertauscht haben.
Ein prinzipielles Problem der Passwortabfrage in der beschrieben Form ist, dass Passwortabfragen
sehr oft so arbeiten, dass beim Vergessen eines alten Passwortes ein neues Passwort vergeben wird.
In einem solchen Modell ist kein Schlüssel zum Entschlüsseln des Passwortes erforderlich.
Benutzer erwarten sich daher in der Regel auch nicht, dass sie einen Kontoschlüssel brauchen. Zu
diesem Zweck ist es erforderlich, dass dem Benutzer das System der Passwortabfrage erklärt wird.
Dabei besteht wieder das Problem, dass Texte zur Erklärung aus Zeitgründen bestenfalls
überflogen, jedoch kaum gelesen werden. Es reicht jedoch oft schon aus, dass der Benutzer weiß,
Walter Sunk 75

5 Benutzungstests 30. August 2006
dass der Kontoschlüssel irgend etwas mit der Passwortabfrage zu tun hat. Beim Durchführen der
Passwortabfrage wird der Benutzer auf die Mail, die den Kontoschlüssel beinhaltet, hingewiesen.
Hat der Benutzer nun eine Assotiation „Passwort vergessen – Kontoschlüssel“ im Kopf, dann liest
der Benutzer normalerweise genauer nach und besteht dann in der Regel auch die Passwortabfrage.
Kauf von Dokumentationen
Wie in Abschnitt 3.1.4 gezeigt, muss sich ein Benutzer zuerst anmelden und sein Guthaben
aufladen, bevor er Dokumentationen kaufen kann. Nachdem der Benutzer in der Regel bei der
entsprechenden Dokumentation startet, möchte er nach der Anmeldung und nach Aufladung des
Guthabens wieder zur Dokumentation zurück, um diese zu erwerben. Der Benutzer muss daher
sowohl nach der Anmeldung als auch nach der Aufladung des Guthabens zur entsprechenden
Dokumentation zurück geleitet werden. Dafür sind geeignete Maßnahmen zu treffen.
Schwierigkeitsbewertung
Gemäß Abschnitt 3.2.2 werden die Schwierigkeiten jeder Tour anhand von international
anerkannten Bewertungsskalen bewertet. Diese Bewertungsskalen sind jedoch nicht einem jeden
Benutzer bekannt. Daher müssen derartige Bewertungsangaben erklärt werden. Bei praktisch jedem
Benutzungstest wurde Kritik daran geübt, dass die Bewertungsskalen nicht erklärt waren. Aus
diesem Grund wurde eine Einführung in die Schwierigkeitsbewertung herausgegeben und mit Links
zu den Herausgebern der Bewertungsskalen versehen.
5.3 Sicherheit versus Benutzerfreundlichkeit
Eine größere Benutzerfreundlichkeit erhöht die Beliebtheit und die Freude am Umgang einer jeden
Internetseite. Im einfachsten Fall erreicht man eine größere Benutzerfreundlichkeit, indem man
Inhalte übersichtlich darstellt, Interaktionen möglichst einfach gestaltet und dem Benutzer
möglichst wenig administrativen Text zu lesen gibt.
Damit kommt es aber oft vor, dass die Benutzerfreundlichkeit dem Aufbau einer sicheren
Internetseite widerspricht. Der Einsatz bestimmter Sicherheitsmaßnahmen auf einer Internetseite
bedeutet auch ein Minimum an zusätzlichen Inhalten, Interaktionen und Texten, wie im folgenden
diskutiert wird.
Einfachheit bei der Passworteingabe
Wie in Abschnitt 5.1 beschrieben gab es einige Probleme beim Verlangen von Passwörtern mit
mindestens einem Groß­ einem Kleinbuchstaben und einer Zahl. Es ist aber genau diese Maßnahme
die den Benutzeraccount ganz wesentlich vor dem erfolgreichen Probieren von Passwörtern schützt.
Im Sinne der Benutzerfreundlichkeit müsste man etwa einfache Namen als Passwörter erlauben und
dürfte erst gar nicht zwischen Groß­ und Kleinschreibung unterscheiden. Aus Sicht der Internet
Security gemäß [InetSec] ist dies jedoch untragbar, weil man solche schwachen Passwörter viel zu
leicht erraten und dadurch Benutzeraccounts missbrauchen kann.
Eine Möglichkeit, Passwörter sicherer zu gestalten und dennoch den Benutzer nicht einzuschränken,
ist etwa die Anzeige der „Sicherheit des Passwortes“ bei der Eingabe. Z.B. könnte man die
Buchstaben direkt bei der Eingabe eines Passwortes analysieren und dann einen Sicherheitsfaktor
berechnen und diesen anzeigen. Ist der Benutzer mit dem Sicherheitsfaktor unzufrieden, muss er das
Passwort ändern. Gute Sicherheitsfaktoren sollten dann nur mit starken Passwörtern erreichbar sein.
Diese Methode erhöht zwar die Akzeptanz eines sichereren Passworts, es besteht aber immer noch
Walter Sunk 76

5 Benutzungstests 30. August 2006
die Gefahr, dass Benutzer schwache Passwörter eingeben.
Einfachheit von Captchas
Wie in Abschnitt 5.1 gezeigt wurden mehrere Fehleingaben beim Lösen eines Captchas als
besonders ärgerlich empfunden. Zwecks Benutzerfreundlichkeit wurden die verwendeten Captchas
daher relativ einfach gestaltet (lediglich 6 Buchstaben, keine Unterscheidung zwischen Groß­ und
Kleinschreibung, keine Verwechslungsmöglichkeiten zwischen Buchstaben, relativ leicht lesbare
Buchstaben). Aus Sicht der Internet Security gemäß [InetSec] sollten Codes jedoch generell
möglichst stark sein. Im Gegensatz zur Passwortabfrage wird hier folgende Strategie verfolgt.
Nachdem bei Captchas die Benutzerfreundlichkeit eine wesentliche Rolle spielt, soll ein Angriff
zugunsten dieser nicht zu 100% verhindert werden, sondern es reicht, wenn der Angreifer soviel
Arbeit zum Durchführen des Angriffs hat, dass er in der Regel von einem Angriff Abstand nimmt,
auch wenn der Angriff theoretisch durchführbar wäre. Jeder Angriff bedeutet Zeitaufwand für den
Angreifer. Zum Brechen eines Captchas muss in der Regel ein eigenes Programm erstellt werden,
was wiederum einiges an Zeit kostet. Im weiteren ist ein eigenes Programm notwendig, welches die
notwendigen Request erzeugt. Das Captcha soll also bewirken, dass ein großer Teil an potentiellen
Angreifern erst gar keinen Angriff durchführt. Sollte dennoch einmal ein Captcha gebrochen und
die Internetseite angegriffen werden, dann existieren laufende Datenbank­Backups, mit denen die
betroffenen Datenbanktabellen wieder bereinigt werden können. Es sollte also für die
Administration ein nicht zu großer Aufwand sein, einen Angriff zu bereinigen.
Angriffe sind außerdem rechtswidrig. Im Falle eines Angriffs wird versucht, den Benutzer über die
IP­Adresse herauszufinden. Sämtliche Provider sind in einem solchen Fall rechtlich verpflichtet
(Österreichisches Recht: ECG (E­Commerce Gesetz) §18, (4)), Auskunft über die entsprechenden
IP Adressen zu geben. Es besteht also kein Datenschutz für den Angreifer. Wird ein Benutzer
gefunden, dann wird Anzeige erstattet und Schadenersatz gefordert.
Einfachheit von Interaktionen mit E­Mails
Wie in Abschnitt 5.1 beschrieben bestehen eine Vielzahl von Problemen, wenn Benutzern E­Mails
mit auszuführenden Links zugeschickt werden. Derartige E­Mails können nicht weiter als in
Abschnitt 5.1 vereinfacht werden. Eine weitere Vereinfachung hieße, die E­Mail erst gar nicht zu
schicken. Dadurch könnte dann aber der Benutzer nicht mehr verifiziert werden, was gegen jeden
Grundsatz der Internet Security gemäß [InetSec] spricht. Es empfiehlt sich daher, in diesem Fall
keine weiteren Vereinfachungen zu treffen.
Einfachheit von Texten
Aufgrund der Erklärung von Sicherheitsmaßnahmen ist es oft notwendig, Texte zu verfassen, die
dann von Benutzern gelesen werden müssen. Aus Sicht der Benutzerfreundlichkeit müssten
derartige Text überhaupt gänzlich entfallen. Dennoch kann ein Kompromiss gefunden werden.
Dieser Kompromiss zwischen Internet Security und Benutzerfreundlichkeit könnte darin bestehen,
dass Texte so aufgebaut sind, dass sie nicht notwendigerweise vollständig gelesen werden müssen,
jedoch der Benutzer die wesentlichsten Inhalte zumindest wahrnimmt und dadurch weiß, wo er
nachsehen muss, wenn er mehr Informationen braucht.
Walter Sunk 77

6 Rechtliche Grundlagen 30. August 2006
6 Rechtliche Grundlagen
Im diesem Kapitel werden die wichtigsten österreichischen Gesetzte sowie die wichtigsten
rechtlichen Grundlagen für den Betrieb der Internetplattform besprochen. Einer der wichtigsten
Punkte für eine Bergsportplattform ist die Frage nach der Verantwortung für zur Verfügung
gestellte Informationen. Zu diesem Zweck wird in Abschnitt 6.1 die Providerhaftung diskutiert.
Nachdem auf der Plattform Verkäufe stattfinden, werden die wichtigsten rechtlichen Grundlagen für
online Geschäfte in Abschnitt 6.2 diskutiert. Ein jeder Provider sendet aus wirtschaftlichen Gründen
gerne Werbemails. Aus rechtlicher Sicht bestehen hierfür jedoch gewisse Voraussetzungen, die in
Abschnitt 6.3 erörtert werden. Um die Privatsphäre von Kunden zu schützen, werden in Abschnitt
6.4 wichtige Punkte des Datenschutzes und Maßnahmen zur Geheimhaltung von Kundendaten
besprochen. Außerdem werden in Abschnitt 6.4 Maßnahmen zum urheberrechtlichen Schutz des
Dokumentationsmaterials sowie zur Vorbeugung von Urheberrechtsverletzungen vorgestellt. Den
Abschluss bildet Abschnitt 6.5 mit einer Diskussion von rechtlichen und steuerlichen
Voraussetzungen, um als Autor tätig zu werden.
In den folgenden Abschnitten werden für die diskutierten österreichischen Gesetze deren
gebräuchliche Abkürzungen verwendet, die nachfolgend zusammengestellt sind.
• ECG E­Commerce Gesetz
• TKG Telekommunikationsgesetz
• AGBG Allgemeines Bürgerliches Gesetzbuch
• EVÜ Europäisches Schuldvertragsübereinkommen
• KSchG Konsumentenschutzgesetz
• DSG Datenschutzgesetz
• UrhG Urhebergesetz
Aus rechtlichen Gründen sind alle nachfolgenden Informationen ohne Gewähr, sie dienen lediglich
der Orientierung in den beschriebenen komplexen Gebieten der Rechtswissenschaften. Eine gute
Darstellung und Zusammenfassung der wichtigsten nachfolgend diskutierten Paragraphen findet
sich in [StFi04]. Die aktuelle geltende Fassung des gesamten Bundesrechts der Republik Österreich
kann vom Rechtsinformationssystem des Bundeskanzleramtes bezogen werden (siehe [RIS]). Zur
effizienten Suche nach Gesetzesstellen im Rechtsinformationssystem können die beschriebenen
Abkürzungen der jeweiligen Gesetze verwendet werden.
6.1 Providerhaftung
Die Bergsportplattform stellt Informationen im Internet zur Verfügung, sie ist also ein Provider von
Informationen. Daher stellt sich auch die Frage, für welche Informationen die Plattform
Verantwortung zu übernehmen hat. Um diese Frage zu beantworten, werden zuerst rechtliche
Formen von Internet Providern und Anbietern diskutiert. Danach werden die Verantwortlichkeiten
der Internetplattform erörtert.
Provider und Anbieter
Gemäß [LawTU] ist grundsätzlich zwischen 4 Arten von Internet Providern zu unterscheiden. Das
sind Access, Caching, Hosting und Content Provider. Weitere Formen von Providern sind Anbieter
von Suchmaschinen und Anbieter von Hyperlinks. Wichtig ist auch den Umfang der Pflichten der
Provider und Anbieter zu kennen. Nachfolgend werden die genannten Diensteanbieter und der
Umfang deren Pflichten beschrieben.
Walter Sunk 78

6 Rechtliche Grundlagen 30. August 2006
Access Provider
Gemäß ECG §13 (1) ist ein Access Provider ein „Diensteanbieter, der von einem Nutzer
eingegebene Informationen in einem Kommunikationsnetz übermittelt oder den Zugang zu einem
Kommunikationsnetz vermittelt“. Ein Access Provider ist gemäß ECG §13 (1) für die übermittelten
Informationen nicht verantwortlich, wenn er folgende Punkte einhaltet:
• er darf die Übermittlung der Daten nicht veranlassen
• er darf den Empfänger nicht auswählen
• er darf übermittelte Informationen weder auswählen noch verändern
Caching Provider
Gemäß ECG §15 ist ein Caching Provider ein Diensteanbieter, der Informationen in einem
Kommunikationsnetz zwischenspeichert. Ein Caching Provider ist im wesentlichen gemäß ECG
§15 für die Zwischenspeicherung nicht verantwortlich, wenn er folgende Punkte einhaltet:
• er darf Informationen nicht verändern
• er muss Informationen unverzüglich entfernen, wenn er davon Kenntnis erhalten hat, dass die
betreffenden Informationen rechtswidrig sind
Hosting Provider
Gemäß ECG §16 (1) ist ein Hosting Provider ein „Diensteanbieter, der von einem Nutzer
eingegebene Informationen speichert“. Ein Hosting Provider ist für die gespeicherten Informationen
des Benutzers nicht verantwortlich, wenn er folgende Punkte einhaltet:
• er darf von einer gespeicherten rechtswidrigen Information eines Benutzers keine tatsächliche
Kenntnis haben
• wenn er eine Kenntnis erhalten hat, dann muss er die rechtswidrige Information entfernen oder
zumindest den Zugang zu dieser Information sperren
Content Provider
Content Provider sind gemäß TKG §78 (2) „Inhaber von Telekommunikationseinrichtungen“.
Gemäß [LawTU] fallen darunter Internet Provider, die keine Access, Caching oder Hosting
Provider sind. Content Provider stellen also eigenen oder zu eigen gemachten Inhalt zur Verfügung.
Gemäß TKG §78 (2) haben Content Provider die Aufgabe, „geeignete Maßnahmen zu treffen, um
eine missbräuchliche Verwendung auszuschließen“. Einen Content Provider trifft daher gemäß
[LawTU] die volle Haftung für eigene bzw. für zu eigen gemachte Inhalte.
Anbieter von Suchmaschinen
Im weiteren sind auch Suchmaschinen von der Verantwortlichkeit ausgeschlossen. Ein Anbieter
einer Suchmaschine ist gemäß ECG §14 (1) für die abgefragten Informationen nicht verantwortlich,
wenn er folgende Punkte einhaltet:
• er darf die Übermittlung der abgefragten Informationen nicht veranlassen
• er darf den Empfänger der Informationen nicht auswählen
• er darf die abgefragten Informationen nicht auswählen und nicht verändern
Anbieter von Hyperlinks auf externe Seiten
Ein Anbieter von Hyperlinks auf externe Seiten ist gemäß ECG §17 (1) für die fremden
Informationen nicht verantwortlich, wenn er folgende Punkte einhaltet:
Walter Sunk 79

6 Rechtliche Grundlagen 30. August 2006
• er darf von rechtswidrigen Informationen auf der verlinkten Seite keine Kenntnis haben
• sobald er Kenntnis über rechtswidrige Informationen auf der verlinkten Seite erhält, muss er
den Link unverzüglich löschen
Umfang der Pflichten der genannten Diensteanbieter
Der Umfang der Pflichten der genannten Diensteanbieter wird in ECG §18 geregelt. Die wichtigste
Aussage ist dabei, dass gemäß ECG §18 (1) alle Diensteanbieter außer Content Provider nicht
verpflichtet sind, Informationen allgemein zu überwachen. Diese Diensteanbieter müssen also nur
dann handeln, wenn sie Kenntnis über rechtswidrige Informationen erlangen. Eigenständiges
Suchen nach rechtswidrigen Informationen ist nicht notwendig.
Im Gegensatz dazu sind Content Provider für Ihre Inhalte verantwortlich. Ein Content Provider
muss gemäß [LawTU] regelmäßig seine Inhalte gegen Rechtswidrigkeit prüfen. Um für fremde
Inhalte auf der eigenen Internetseite nicht verantwortlich zu sein, muss ein Content Provider gemäß
[LawTU] klar ersichtlich machen, wenn Einträge von dritten sind.
Diskussion der Verantwortlichkeiten
Auf der Bergsportplattform verkaufen Autoren Dokumentationen direkt an Kunden. Die
Bergsportplattform tritt in diesem Fall als Hosting Provider auf, der von einem Nutzer eingegebene
Informationen speichert. Nachdem die Bergsportplattform aber auch selbst Inhalte zur Verfügung
stellt, ist sie gleichermaßen auch ein Content Provider und hat dafür zu sorgen, dass keine
rechtswidrigen Inhalte vorkommen.
Im weiteren bietet die Bergsportplattform Hyperlinks auf externe Seiten an. Gemäß [LawTU] ist bei
der Verlinkung auf externe Seiten jedoch darauf zu achten, dass der fremde Inhalt nicht als eigener
Inhalt dargestellt wird, indem beispielsweise die fremde Seite in einem Frame der eigenen Seite
geladen wird. Im Falle, dass fremde Inhalte zu eigenen Inhalten gemacht werden, besteht eine
Verantwortung für diese Inhalte. Links auf externe Seiten sollten daher immer in einem eigenen
neuen Browserfenster geöffnet werden.
6.2 Geschäfte im Internet
Nachdem zu jedem Geschäft ein Vertrag existiert, muss geklärt werden, wie bei Geschäften im
Internet Verträge zustande kommen und welche Pflichten der Verkäufer eines Geschäfts hat.
Online Vertragsabschluss
Verträge kommen gemäß AGBG §861 grundsätzlich formlos durch übereinstimmende
Willenserklärungen der beteiligten Personen zustande. Bei Kaufverträgen sind gemäß [LawTU] für
einen Vertragsabschluss zusätzlich Kaufgegenstand und Preis erforderlich. Grundsätzlich können
Verträge dabei mündlich, fernmündlich, schriftlich und digital abgeschlossen werden. Für den
Abschluss eines Kaufvertrages im Internet ist gemäß ECG §10 (2) zusätzlich eine unverzügliche
Bestätigung des Verkäufers (z.B. durch eine E­Mail) notwendig. Ein Vertragsabschluss zu einem
Kaufvertrag im Internet entsteht daher wie folgt:
1.) Der Verkäufer gibt Auskunft über sein Produkt auf der Webseite. Im Bestellformular müssen
Preis und Steuern klar ersichtlich sein (Preis und Kaufgegenstand sind also gegeben).
2.) Der Käufer bestellt das Produkt, z.B. durch Abschicken eines Web­Formulars. Die Bestellung
entspricht dabei der Willenserklärung des Käufers, das Produkt zu kaufen.
Walter Sunk 80

6 Rechtliche Grundlagen 30. August 2006
3.) Der Verkäufer muss den Vertrag unverzüglich elektronisch bestätigen (z.B. durch eine E­
Mail). Die Bestätigung entspricht der Willenserklärung des Verkäufers.
Geltendes Recht bei internationalen Verträgen
Grundsätzlich gilt für Verträge gemäß EVÜ Art. 3 eine freie Rechtswahl. Der Vertrag unterliegt
dem Recht, dass die beiden Parteien gewählt haben. Sollten die beiden Parteien kein Recht wählen,
dann kommen Art. 4 und Art. 5 des EVÜ zur Anwendung.
Ist das Recht nicht vereinbart worden, dann unterliegt gemäß EVÜ Art. 4 der Vertrag „dem Recht
des Staates, mit dem er die engsten Verbindungen aufweist“. Gemäß [LawTU] bedeutet das, dass
das Recht des Verkäuferlandes anzuwenden ist.
Eine Ausnahme bilden jedoch Verbraucherverträge (das sind Verträge zwischen Unternehmen und
Konsumenten). Wird keine Rechtswahl getroffen, dann gilt gemäß EVÜ Art. 5 (3) das Recht des
Verbraucherlandes (also des Staates des Käufers).
Für die Anwendung auf einer Internetseite bedeutet dies gemäß [LawTU], dass das geltende Recht
und der Gerichtsstand stets vereinbart werden sollten, um nicht böse Überraschungen zu erleben.
Werden Verträge unter Allgemeinen Geschäftsbedingungen (AGB) abgeschlossen, dann sollten
geltendes Recht und Gerichtsstand in den AGB enthalten sein.
Allgemeine Geschäftsbedingungen (AGB)
Gemäß [WPR104] sind Allgemeine Geschäftsbedingungen „vorformulierte Vertragsinhalte, die
Unternehmer als Grundlage für eine Vielzahl gleicher Verträge verwenden“. Gibt ein Unternehmer
AGB heraus, dann werden diese gemäß [WPR104] unter gewissen Voraussetzungen zum
Vertragsinhalt eines jeden Kaufvertrags. Notwendige Voraussetzungen dafür, dass AGB zum
Vertragsinhalt werden sind:
• der Kunde muss erkennen können, dass der Unternehmer nur zu seinen AGB abschließt
• die AGB müssen vom Kunden zumutbar zur Kenntnis genommen werden können
Ein Kunde muss daher nur die Möglichkeit haben, die AGB lesen zu können, braucht sie aber nicht
lesen, wenn er nicht möchte. Beim Formulieren der einzelnen Vertragsbestimmungen ist auf
folgende Punkte zu achten:
• eine Vertragsbestimmung ist gemäß ABGB §879 (3) nicht gültig, wenn diese gröblich
benachteiligend ist
• ungewöhnliche Vertragsbestimmungen werden gemäß ABGB §864a kein Vertragsbestandteil,
außer der Unternehmer weist gesondert darauf hin
Für AGB im Internet gelten gemäß ECG gesonderte Regelungen. Gemäß ECG §11 müssen AGB
gespeichert und wiedergegeben werden können. Gemäß [LawTU] sollten AGB auf einer
Internetseite daher wie folgt angebracht werden:
• schnell auffindbar
• ausdruckbar
• gut lesbar
• mit Gültigkeitsdatum
Auf der Bergsportplattform sollten die AGB also stets leicht auffindbar sein. Nachdem es
vorkommen kann, dass auf Touren Unfälle passieren, sollte auch gesondert darauf hingewiesen
werden, dass die Bergsportplattform für Unfälle jeglicher Art keine Verantwortung übernimmt. Aus
Walter Sunk 81

6 Rechtliche Grundlagen 30. August 2006
diesem Grund wird auf der Bergsportplattform ein eigener Haftungsausschluss herausgegeben, der
Bestandteil der AGB ist. Bevor ein Kunde Dokumentationen erwirbt, muss er daher aus
Haftungsgründen die AGB und den Haftungsausschluss akzeptieren.
Nutzungsbedingungen
Werden keine Allgemeinen Geschäftsbedingungen herausgegeben, dann sollten gemäß [LawTU]
auf jeder Internetseite zumindest Nutzungsbedingungen vorhanden sein, die beschreiben, unter
welchen Bedingungen die Internetseite verwendet werden darf. Die herausgegebenen
Nutzungsbedingungen sollten auch Verantwortlichkeiten auf der Seite festhalten, insbesondere
dann, wenn keine Verantwortung für bestimmte Inhalte übernommen wird.
Informationspflichten (Impressum)
Gemäß ECG §5 hat ein Diensteanbieter einige Informationen zur Verfügung zu stellen. Die
Informationen müssen dabei leicht auffindbar sein. Diese Informationen sind:
• Name oder Firmenname
• die geographische Anschrift
• die E­Mail Adresse des Herausgebers
• bei Firmen weiters: Firmenbuchnummer, Aufsichtsbehörde, Kammer, Berufsverband,
Umsatzsteueridentifikationsnummer (UID)
• bei Preisangaben muss angegeben werden, ob Preise inkl. oder exkl. Umsatzsteuer sind;
Preisangaben müssen überdies leicht lesbar und zuordbar sein
6.3 Versand von Werbemails
Für den Versand von Werbemails ist gemäß [LawTU] das TKG zuständig. Folgende Regelungen
werden getroffen:
• gemäß TKG §107 (2) ist der Versand einer E­Mail ohne vorherige Einwilligung des
Empfängers unzulässig, wenn es sich entweder um eine Werbemail handelt oder die Mail an
mehr als 50 Empfänger gerichtet ist
• gemäß TKG §107 (3) ist eine vorherige Zustimmung eines Kunden (genauer gesagt, eines
Verbrauchers im Sinne des KSchG §1 Abs. 1 Ziff. 2) nicht notwendig, wenn folgende
Kriterien erfüllt sind:
1) der Absender hat die Adresse des Kunden im Zuge eines Verkaufs oder einer
Dienstleistung erhalten, und
2) der Inhalt der E­Mail ist eine Direktwerbung für ähnliche Produkte, und
3) der Kunde hat die Möglichkeit erhalten und hat weiterhin die Möglichkeit, Werbemails
kostenfrei und problemlos abzulehnen
• gemäß TKG §107 (4) dürfen Werbemails an Unternehmer ohne vorherige Einwilligung dieser
gesendet werden, wenn der Empfänger ausdrücklich die Möglichkeit hat, den Empfang
weiterer E­Mails abzulehnen
Gemäß TKG §107 (2) und (3) dürfen also erst dann Werbemails gesendet werden, wenn man bereits
vorher mit dem Kunden in Kontakt getreten ist und der Kunde keine Einwände gegen Werbemails
hat. In der praktischen Implementierung muss in jeder Werbemail ein Link vorhanden sein, mit dem
zukünftige Werbemails abgelehnt werden können.
Walter Sunk 82

6 Rechtliche Grundlagen 30. August 2006
Um die Zustimmung eines Kunden explizit zu erfragen, ist es angebracht, z.B. im Verlauf der
Registrierung des Kunden zu fragen, ob dieser Werbemails (z.B. einen Newsletter) zugeschickt
bekommen möchte. Diese Einstellung sollte im Profil des Kunden auf jeden Fall änderbar sein.
Vielleicht möchte der Kunde z.B. im Falle eines Newsletters diesen vorerst nicht zugeschickt
bekommen, aber vielleicht nach ein paar Wochen, nachdem er die Internetseite kennen gelernt hat.
In diesem Fall sollte der Kunde in seinem Profil den Newsletter abonnieren können.
Bei allen E­Mails ist zu achten, dass sofort erkennbar ist, wer der Absender der E­Mail Adresse ist.
Der Absender muss auch gemäß ECG §7 (1) leicht und eindeutig identifizierbar sein. Der Kunde
sollte bereits durch die E­Mail Adresse selbst oder mit dem Betreff die E­Mail zuordnen können.
E­Mails an Unternehmer dürfen also gemäß TKG §107 (4) prinzipiell ohne deren Einwilligung
gesendet werden, wenn die Möglichkeit des Ablehnens besteht. Gemäß [LawTU] ist jedoch zu
beachten, dass der Inhalt der E­Mail mit dem angemailten Unternehmen in Bezug stehen muss.
Steht der Inhalt der E­Mail nämlich nicht mit dem angemailten Unternehmen in Bezug, dann ist das
Unternehmen als ein Verbraucher zu werten. In diesem Fall müssen dann TKG §107 (2) und TKG
§107 (3) angewendet werden.
6.4 Datenschutz und Urheberrecht
Datenschutz
Gemäß [LawTU] schützt das Datenschutzgesetz die Privatsphäre und die Meinungsfreiheit. Gemäß
DSG §6 (1) dürfen Daten nur für eindeutige und rechtmäßige Zwecke erhoben werden. Die Daten
müssen aktualisiert werden können. Daten dürfen nur solange aufbewahrt werden, solange sie für
ihre Zwecke gebraucht werden. Gemäß DSG §7 dürfen Daten nur mit der Einwilligung des
Betroffenen verarbeitet werden, die Notwendigkeit der Verarbeitung muss klar ersichtlich und die
Daten müssen geheim gehalten werden.
Nachdem es auf der Bergsportplattform verschiedene Benutzergruppen gibt, muss die Frage gestellt
werden, welche Daten von jeder Benutzergruppe benötigt werden.
Nachdem auf der Plattform Autoren Dokumentationen direkt an Kunden verkaufen, entstehen somit
Verträge zwischen Kunden und Autoren. Um die an einem Kaufvertrag beteiligten Personen
identifizieren zu können, werden von Kunden und Autoren personenbezogenen Daten gespeichert.
Die genaue Identifizierung der an einem Kaufvertrag beteiligten Personen kann im Falle von
Rechtswidrigkeiten und Rechtsstreitigkeiten notwendig sein. Nachdem Autoren auf der Plattform
als Unternehmer (in der Regel als Kleinunternehmer, siehe Abschnitt 6.5) auftreten, müssen von
den Autoren weiters Daten gemäß ECG §5 aufgenommen und beim Kauf einer Dokumentation an
den jeweiligen Kunden ausgewiesen werden.
Nachdem Werbeverträge mit Werbern und Übersetzungsverträge mit Übersetzern abgeschlossen
werden, müssen auch personenbezogene Daten von Werbern und Übersetzern hinreichend genau
aufgenommen werden.
Um zu gewährleisten, dass alle personenbezogenen Daten auf einem aktuellen Stand gehalten
werden können, können alle Benutzergruppen ihre personenbezogen Daten in ihrem Profil im
Bereich für Mitglieder updaten. Um zu gewährleisten, dass personenbezogene Daten geheim
gehalten werden, sind diese nur der Administration für administrative Zwecke zugänglich. Um die
Geheimhaltung bei der Datenübertragung zu gewährleisten, unterstützt die Bergsportplattform die
Verschlüsselungsart SSL. Sensible Daten werden daher nur über verschlüsselte HTTPS­
Verbindungen (die SSL verwenden) übertragen. Um sensible personenbezogene Daten überdies vor
Walter Sunk 83

6 Rechtliche Grundlagen 30. August 2006
Angriffen zu schützen, werden diese in der Datenbank verschlüsselt gespeichert. Um diese Daten zu
entschlüsseln sind besondere Rechte sowie die zugehörigen Passwörter notwendig.
Urheberrechtsgesetz
Gemäß dem UrhG Abschnitt III. hat ein Urheber eines Werkes das ausschließliche Recht zu
bestimmen, ob und wann das Werk genutzt, verwertet, vervielfältigt oder verbreitet wird. Der
Urheber hat weiters das Recht, gemäß UrhG §20 (1) genannt zu werden oder anonym zu bleiben.
Diese Forderungen haben großen Einfluss auf die Bergsportplattform. Auf der Bergsportplattform
wird Literatur kombiniert mit Fotos angeboten. Literatur und Fotos sind urheberrechtlich geschützt.
Zum einen müssen die urheberrechtlichen Interessen der Autoren geschützt bleiben, zum anderen
muss darauf geachtet werden, dass Autoren in ihren Dokumentationen keine
Urheberrechtsverletzungen begehen.
Um die urheberrechtlichen Interessen der Autoren zu schützen, wird in jeder Dokumentation auf
den Autor hinweisen. Zudem ist auf allen Fotos der Autor als Urheber ersichtlich und das
Copyright­Log © ist angebracht. Im weiteren ist in allen PDF­Dokumenten der jeweilige Autor als
Urheber ersichtlich. In den Allgemeinen Geschäftsbedingungen für Kunden wird mit Kunden
vereinbart, dass Dokumentationen nur in eigenem privaten Gebrauch verwendet werden dürfen.
Dokumentationen und deren Inhalte dürfen von Kunden weder veröffentlicht noch weitergegeben
werden. Diese Bestimmungen werden zusätzlich in den PDF­Dokumenten wiedergegeben.
Umgekehrt muss darauf geachtet werden, dass Autoren keine Urheberrechtsverletzungen begehen.
Nachdem es aufgrund schlechten (oder nicht hinreichend guten) Wetters oftmals schwer ist, gute
Fotos für Dokumentationen zu erhalten, kann es Vorkommen, dass Autoren zusätzliche Fotos, die
nicht von ihnen stammen, verwenden möchten. Aufgrund des UrhG dürfen Autoren jedoch
prinzipiell nur eigenes Dokumentationsmaterial verwenden. Sollten Autoren dennoch fremdes
Material (z.B. fremde Fotos) verwenden wollen, dann müssen sie sich für dieses die notwendigen
Nutzungsrechte der Urheber besorgt haben. Hält sich ein Autor nicht an diese Bestimmung, dann
wird ihm die Autorenlizenz fristlos entzogen. Nachdem im Dokumentationsmaterial potentiell
Urheberrechtsverletzungen seitens der Autoren auftreten können, muss mit jedem Autor zusätzlich
vereinbart werden, dass der Autor im Falle eines durch ihn verschuldeten Rechtsstreits die Plattform
„schad­ und klaglos“ halten muss.
6.5 Tätigkeit als Autor
In diesem Abschnitt werden die wichtigsten rechtlichen und steuerlichen Voraussetzungen für die
Tätigkeit als Autor in Österreich erklärt. Nachfolgende Informationen wurden bei den zuständigen
Behörden recherchiert und dienen lediglich der Orientierung. Für rechtsgültige und aktuelle
Informationen sind das zuständige Finanzamt, die zuständige Wirtschaftskammer sowie die
zuständige Sozialversicherung zu kontaktieren. Die Wirtschaftskammern Österreichs geben unter
anderem einen Leitfaden für Gründer und Gründerinnen von Unternehmen mit vielen wichtigen
Hinweisen und wichtigen Adressen heraus (siehe [WkOe05]).
Autor bzw. Schriftsteller – ein freier Beruf
Literatur und Selbstverlag der Urheber sind in Österreich kein Gewerbe. Dementsprechend
brauchen Autoren auch keinen Gewerbeschein. Dadurch kann eine jede Person jederzeit eine
Tätigkeit als Autor beginnen.
Walter Sunk 84

6 Rechtliche Grundlagen 30. August 2006
Umsatzsteuer, Unternehmer und Kleinunternehmer
Beim Verkauf von Dokumentationen wird „Online Literatur“ verkauft. Generell ist „Online
Literatur“ in Österreich mit 20% Umsatzsteuer zu versteuern. Gemäß österreichischem Gesetzt kann
man bis zu einem jährlichen Umsatz von 22.000€ als Kleinunternehmer arbeiten. Die Umsätze von
Kleinunternehmern sind von der Umsatzsteuer befreit (UStG §6, Abs. 1, Ziff. 27). Wenn man im
laufenden Jahr die Grenze von 22.000€ Umsatz überschreitet, dann muss man sich selbstständig
beim Finanzamt melden und Umsatzsteuer (20% vom Verkaufspreis) an das Finanzamt abführen.
Bedenklich bei dieser steuerlichen Situation ist, dass Literatur in Buchform der ermäßigten
Umsatzsteuer von 10% unterliegt. Für alle Waren­ und Dienstleistungen, die der ermäßigten
Umsatzsteuer von 10% unterliegen, existiert eine Liste. Paradoxerweise ist für „Online Literatur“
nur deshalb nicht die ermäßigte Umsatzsteuer von 10% anzuwenden, weil in dieser Liste nur
Literatur, aber nicht „Online Literatur“ vorkommt – eine Auslegung mit weitreichenden
Konsequenzen, die aus Sicht eines Autors und Schriftstellers kaum einsichtig ist.
Sozialversicherung
Wenn man die Tätigkeit als Autor in Österreich nebenberuflich ausübt und wenn der jährliche
Gewinn 3997.92€ (Wert 2006) übersteigt, dann muss man Sozialversicherung zahlen. Man muss
sich in diesem Fall selbstständig bei der Sozialversicherung melden.
Zusammenfassung:
Eine jede Person kann also eine Tätigkeit als Autor jederzeit beginnen. Übersteigt der jährliche
Umsatz 22.000€, dann muss man sich beim Finanzamt melden und den Umsatz mit 20%
Umsatzsteuer versteuern. Übersteigt der jährliche Gewinn 3997.92€, dann muss man sich bei der
Sozialversicherung melden und Sozialversicherung zahlen. Bleibt man unter diesen Grenzen, dann
kann man die Tätigkeit als Autor frei (ohne Versteuerung und ohne Meldung bei einem Amt)
ausüben.
Walter Sunk 85

7 Zusammenfassung und Ausblick 30. August 2006
7 Zusammenfassung und Ausblick
7.1 Ergebnisse der Arbeit
Ergebnisse aus inhaltlicher Sicht
Im Zuge dieser Arbeit wurde die Bergsportplattform [AIS] entwickelt, die es ermöglicht,
fotounterstützte Dokumentation alpiner Touren im Internet zu publizieren und zu vermarkten.
Derartige Dokumentationen unterstützten dabei durch gut aufbereitetes und informatives
Fotomaterial die Tourenplanung alpiner Touren. Die Plattform wurde mehrsprachig entwickelt,
sodass Dokumentationen auch in mehreren Sprachen erstellt und bezogen werden können.
Basisinhalt der Bergsportplattform
Als Basisinhalt wurden auf der Plattform ein Osttirol Wander­ und Hochtourenführer sowie ein
kleiner Zentralpyrenäenführer mit Sommerbeginn 2006 herausgegeben.
Fotomaterial
Besonderen Wert legt die Plattform auf inhaltlich informative Fotos und deren Aufbereitung in
einer Dokumentation. Die Plattform wurde derart modelliert, dass jede Dokumentation genügend
Fotomaterial aufnehmen kann, um den gesamten Verlauf der dokumentierten Tour sowie deren
Schlüsselstellen zeigen zu können. Jedes Foto kann mit jedem anderen Foto einer Tour direkt im
Foto selbst verlinkt werden. Das selbe gilt auch für Tourenkarten. Auf jeder Karte einer Tour
können Links zu den Fotos der Tour angebracht werden. Der Benutzer sieht dadurch, an welcher
Stelle die Fotos während der Tour aufgenommen wurden und kann somit die gesamte Tour virtuell
durchgehen. Der Verlauf jeder Tour wird in Worten als Text beschrieben, wobei in diesem Links zu
den entsprechenden Fotos (automatisiert) angebracht werden können. Auch anhand des Textes und
der verlinkten Fotos wird der gesamte Tourenverlauf einsehbar.
Touren und Tourenalben
Dokumentationen einzelner Touren können zu sogenannten Tourenalben zusammengefasst werden.
Solche bestehen also aus mehreren Touren, die unter einem gemeinsamen Thema zusammengestellt
sind. Tourenalben realisieren somit Gebietsführer. Tourenalben können von mehreren Autoren
gemeinsam verfasst werden, wodurch Dokumentationen in relativ kurzer Zeit herausgebbar sind.
PDF­Dokumente
Überdies wurde ein PDF­Generator implementiert, der es ermöglicht, sämtliche Inhalte der
Tourendokumentation in Form von 2 PDF­Dokumenten zu beziehen. Ein PDF­Dokument
beschreibt dabei die Tour als Text, das andere PDF­Dokument bietet alle zugehörigen Fotos, die
ausführlich beschrieben sind.
Ergebnisse aus technischer Sicht
Realisierung von Sicherheitsmaßnahmen
Aufgrund des großen Umfangs wurden Teile der Arbeit in die Praktikumsarbeit [WaSu06]
ausgegliedert. In jeder Stufe der vorliegenden Arbeit und der Praktikumsarbeit wurde sowohl bei
der Planung, bei der Modellierung als auch bei der Implementierung stets auf wichtige Themen der
Internet Security gemäß [InetSec] geachtet. Insbesondere betrifft dies jene Bereiche der Arbeit, die
Walter Sunk 86

7 Zusammenfassung und Ausblick 30. August 2006
mit sensitiven Benutzerdaten und mit Geldsummen zu tun haben. Aus technischer Sicht bestand die
Herausforderung auch darin, das eigene System durch gezielte Attacken anzugreifen, um die
Funktionalität der implementierten Sicherheitsmaßnahmen zu testen. Die Realisierung der
Sicherheitsmaßnahmen führte zu einem wichtigen Ergebnis. Die Umsetzung nahm in etwa 2­3 mal
soviel Zeit in Anspruch als dafür geplant. Grund dafür waren stets Detailprobleme. In der Regel war
die Planung nicht ausreichend. Bei der Implementierung kamen Probleme zum Vorschein, die in der
Planung nicht bedacht wurden. Außerdem wurde der zeitliche Aufwand zum Testen ebenfalls
unterschätzt. Ein Hauptproblem bei Tests war, dass diese nur schwer bis überhaupt nicht zu
automatisieren waren, zumindest nicht im vorgegebenen Zeitrahmen.
Fotoerstellung und Schutz des Fotomaterials
Im Zuge der Fotoerstellung war es möglich, Fotos durch Beschreibung von Header­Tags
Annotierung, Wasserzeichen und Steganographie urheberrechtlich zu schützen. In Abschnitt 2.2.2
wurde diskutiert, dass ein 100%­Schutz praktisch nicht möglich ist. Sicherheit musste demzufolge
neu definiert werden. Nach dieser Definition besteht Sicherheit für ein System, wenn für einen
Angreifer der Aufwand zu groß ist, das System anzugreifen. Ein Angriff ist bei dieser Definition
von Sicherheit zwar prinzipiell möglich, jedoch sehr unwahrscheinlich, weil der Aufwand für den
Angriff verglichen mit dem Nutzen für den Angreifer zu groß ist.
Benutzungstests
Wie die in Kapitel 5 beschriebenen Benutzungstests gezeigt haben, muss man auf einer Internetseite
stets mit unerfahrenen Internetbenutzern rechnen. Dabei wurde gezeigt, dass Benutzerfreundlichkeit
oft im Widerspruch zu Internet Security steht. Hier ist gründlich zu überlegen, welche
Sicherheitsmaßnahmen auf einer Internetseite überhaupt notwendig sind, um Interaktionen auf der
Seite nicht unnötig zu erschweren, wodurch Benutzer verärgert werden und die Seite verlassen.
Ergebnisse aus multidisziplinärer Sicht
Rechtliche Grundlagen
Zur Realisierung der Bergsportplattform waren nicht nur technische Kenntnisse erforderlich. Wie in
Kapitel 6 gezeigt sind beim Betrieb einer Internetseite eine Menge rechtlicher Bestimmungen zu
beachten. Nachdem derartige rechtliche Bestimmungen stets sehr komplex sind, sollten hier auf
jeden Fall zumindest einführende Kurse zu diesem Thema besucht werden, um nicht plötzlich böse
Überraschungen zu erleben.
Grundlagen aus der Buchhaltung
Jedem Verkauf von Waren und Dienstleistungen liegt eine Buchhaltung zu Grunde. Um sämtliche
Verrechnungen auf der Plattform automatisch durchführen zu können, wurde in Abschnitt 3.2.12
ein System der doppelten Buchhaltung entwickelt. Hierfür sind bereits teilweise mehr als nur
grundlegende Kenntnisse der Buchhaltung notwendig, die man sich als Techniker meistens erst
aneignen muss, was wiederum sehr viel Zeit kostet.
Grundlagen der Alpinistik
Der Inhalt der gesamten Plattform erfordert natürlich grundlegende Kenntnisse im Bereich der
Alpinistik. Um Inhalte für die Plattform in Form von Dokumentationen zu erstellen, ist außerdem
Erfahrung beim Durchführen von alpinen und hochalpinen Touren notwendig.
Walter Sunk 87

7 Zusammenfassung und Ausblick 30. August 2006
7.2 Ausblick
Bekanntmachung der Internetseite
In kommender Zeit soll die Internetseite öffentlich bekannt gemacht werden. Die Vorgehensweise
ist bereits geplant. Eine Strategie für die weitere Zukunft der Seite soll ausgearbeitet werden.
Implementierung neuer Tourtypen
Mit Sommer 2006 können auf der Plattform Wanderungen und Hochtouren dokumentiert werden.
Zukünftig soll auch die Dokumentation von Wintertouren möglich sein. Insbesondere sollen
zukünftig Skitouren, Skihochtouren und Schneeschuhwanderungen dokumentiert werden können.
Weitere Benutzungstests
Aufgrund des zeitlich beschränkten Rahmens konnte nur eine relativ kleine Anzahl an
Benutzungstests durchgeführt werden. In weiteren Arbeiten könnten folgende zwei Arten von
weiteren Benutzungstests durchgeführt werden.
• Weitere Benutzungstest mit der Internetseite: Im Zuge der bereits durchgeführten
Benutzungstests wurden einige Änderungen an der Seite vorgenommen. Es ist zu testen, ob die
vorgenommenen Änderungen auch wirklich die erwünschten Ergebnisse liefern. Um dies
festzustellen, sind weitere Tests mit neuen Benutzern notwendig.
• Allgemeine Benutzungstests zu bestimmten Interaktionen: Aus Sicht des Entwicklers wäre es
interessant, wie bestimmte Interaktionen aus psychologischer Sicht aussehen müssen, um
möglichst benutzungsfreundlich zu sein. Beispielsweise wäre es interessant zu erfahren, wie
der optimale Captcha­Test (diskutiert in Abschnitt 5.1), wie das optimale Zahlungssystem und
wie die optimale Passwortabfrage aus Sicht der Benutzerfreundlichkeit und aus
psychologischer Sicht aussehen sollen.
Inhaltliche Ziele der Bergsportplattform
Die Verantwortlichen der Plattform möchten gemeinsam mit zukünftigen Autoren professionelle
fotounterstützte Dokumentationen aller bekannten alpinen Gipfelziele des gesamten Alpenraums
anfertigen und somit Wanderern und Bergsteigern wertvolle Informationen zur Tourenplanung
anbieten. Als Zukunftsphilosophie wurde die Erstellung derartiger fotounterstützter
Dokumentationen zu den wichtigsten 3000er und zu allen 4000er Gipfelzielen des gesamten
Alpenraums definiert. Darüber hinaus sollen auch weltweite Gipfelziele außerhalb des Alpenraums
präsentiert werden.
Die Verantwortlichen der Internetseite möchten Alpinsport als Urlaub vermitteln. Mit dem
Grundsatz, dass der Alpinsport einzigartige Erlebnisse mit sich bringt, die in wunderbaren
Erinnerungen über Jahre hinweg Bestand haben, soll die Internetseite einen Beitrag dazu leisten,
derartige Erlebnisse fern vom Alltagsleben zu ermöglichen.
Walter Sunk 88

8 Literatur 30. August 2006
8 Literatur
[AlLp01] DAV (Deutscher Alpenverein): Alpin­Lehrplan Band 3, Hochtouren und Eisklettern.
BLV Verlags­GmbH, 2001
[AmBug02] L. Baresi, G. Denaro, L. Mainetti, P. Paolini: Assertions to Better Specify the
Amazon Bug. Paper vom Politecnico di Milano, Milan, Italien, 2002
[AttWm04] Chun­Hsiang Huang, Ja­Ling Wu: Attacking visible watermarking schemes. Paper,
Multimedia, IEEE Transactions on Volume 6, Issue 1, Pages 16 ­ 30, Feb. 2004
[DigWm99] Wolfgang, R.B.; Podilchuk, C.I.; Delp, E.J.: Perceptual watermarks for digital
images and video. Paper, Proceedings of the IEEE Volume 87, Issue 7,
Pages 1108 ­ 1126, July 1999
[EfBh04] Grohmann­Steiger, Schneider, Eberhartinger: Einführung in die Buchhaltung im
Selbststudium. 16. Auflage, WUV Universitätsverlag, Wien, 2004
[LawTU] Markus Haslinger, Wolfram Proksch: Unterlagen zur Vorlesung und Übung Datenund
Informatikrecht. Fachbereich Rechtswissenschaften der TU Wien (die
Unterlagen sind für Studenten, welche die Vorlesung und Übung besuchen,
kostenfrei im jeweiligen Kurs erhältlich, Wintersemester 2004/2005
[MaKo02] Manfred Korbaj: Die schönsten Dreitausender der Ostalpen. Pichler Verlag, 2002
[PeDo03] Peter Donatsch: Alle 4000er der Alpen. AT Verlag, 2003
[SMail03] Bryan Costalas mit Eric Allman: sendmail. O'Reilly Verlag, 2003
[StFi04] Manfred Straube, Siegfried Fina: E­Commerce und Internetrecht. 2. Auflage, Manz
Verlag, Wien, 2004
[UML205] Martin Hitz, Gerti Kappel: UML@work. 3. aktualisierte und überarbeitete Auflage,
dpunkt.verlag, 2005
[WaSu06] Walter Sunk: Secure top­up payment system and its prerequisites. Praktikum am
Institut für Informationssysteme, TU­Wien, Wien, 2006
[WkOe05] Wirtschaftskammern Österreichs: Leitfaden für Gründerinnen und Gründer. 10.
Auflage, Wien, 2005
[WPR104] Peter Doralt, Christian Nowotny: Wirtschaftsprivatrecht 1. 3. Auflage, Facultas
Verlag, Wien, 2004
Web Links (Letzte Besuche am 8. August 2006)
[AIS] Walter Sunk: www.AlpinImageS.com. Realisierte Bergsportplattform, die
professionelle fotounterstützte Dokumentationen alpiner Touren anbietet,
http://www.AlpinImageS.com /, 2006
[BEV] Bundesamt für Ein­ und Vermessungswesen, http://www.bev.gv.at/, 2006
[CMU] Carnegie Mellon Universität: The Captcha Project. Informationen der Erfinder
zum Captcha Projekt, http://www.captcha.net/, 2002­2005
[i18nW3C] W3C: W3C Internationalization (i18n) Activity. Überblick über die W3C
Aktivitäten zur Internationalisierung, http://www.w3.org/International/, 2006
Walter Sunk 89

8 Literatur 30. August 2006
[i18nDb] Debian: Introduction to i18n. Gute Einführung in die Konzepte der
Internationalisierung, http://www.debian.org/doc/manuals/intro­i18n/, 2006
[IMagick] Anthony Thyssen: Examples of ImageMagick Usage (version 6). Gute Einführung
mit vielen praktischen Beispielen zu ImageMagick,
http://www.cit.gu.edu.au/~anthony/graphics/imagick6/, 2005
[InetSec] Engin Kirda, Christopher Kruegel: Internet Security 1 und 2. Vorlesungen mit
Übungen auf der TU­Wien mit vielen praktischen Beispielen zum Thema Internet
Security, http://www.seclab.tuwien.ac.at/InetSec2/
[KstWiki] Im europäischen Alpenraum gebräuchliche 5­teilige Klettersteigskala,
http://de.wikipedia.org/wiki/Klettersteig
[RIS] Österreichisches Bundeskanzleramt: Rechtsinformationssystem des
Bundeskanzleramts. Informationenen über das Recht der Republik Österreich,
http://www.ris.bka.gv.at/
[SAC] Schweizer Alpen­Club, Herausgeber von Bewertungsskalen zu unterschiedlichen
Tourtypen, http://www.sac­cas.ch/
[UIAA] UIAA, International Mountaineering and Climbing Federation, Herausgeber der 7stufigen
UIAA­Skala für Felsklettern, http://www.uiaa.ch/
Walter Sunk 90