DIONE Abschlussbericht 7. April 2005

DIONE
Abschlussbericht
Data Mining Workbench
für eine ökologische Datenbank
7. April 2005
Teilnehmer
Boris Bensien, Richard Hackelbusch, Sebastian Heisecke,
Niels Henze, Rainer Hilbrands, Heike Kraef, Jörn Künnemann,
Pascal Kuhn, Daniel Meyerholt, Florian Postel und Hauke Tschirner
Betreuer
Prof. Dr. Michael Sonnenschein
Dr. Michael Stadler
Dipl.-Inform. Jens Finke
ii
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 LEDA - Projektübersicht und Datenbankschema . . . . .
2.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Herangehensweise . . . . . . . . . . . . . . . . . .
2.1.4 LEDA Datenstandards . . . . . . . . . . . . . . .
2.2 J2EE, Servlets und JSP . . . . . . . . . . . . . . . . . .
2.2.1 J2EE . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Servlets . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 JSP . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Webapplikationen mit J2EE . . . . . . . . . . . . . . . .
2.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . .
2.3.2 J2EE . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Der Tomcat-Server . . . . . . . . . . . . . . . . .
2.3.4 Web Services . . . . . . . . . . . . . . . . . . . .
2.4 Das Framework Struts . . . . . . . . . . . . . . . . . . .
2.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Model-View-Controller . . . . . . . . . . . . . . .
2.4.3 Der Controller . . . . . . . . . . . . . . . . . . . .
2.4.4 Das Model . . . . . . . . . . . . . . . . . . . . . .
2.4.5 Die View . . . . . . . . . . . . . . . . . . . . . . .
2.4.6 Das Validator Plugin . . . . . . . . . . . . . . . .
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
2.5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Grundlagen . . . . . . . . . . . . . . . . . . . . .
2.5.3 Algorithmen . . . . . . . . . . . . . . . . . . . . .
2.5.4 Optimierung . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
2
3
4
4
5
6
7
17
17
23
26
33
33
33
36
38
45
45
45
46
49
51
56
57
57
58
62
70
iii
Inhaltsverzeichnis
2.6
2.7
2.8
2.9
2.5.5 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . .
Lineare und logistische Regression - Modell und Lernverfahren
2.6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
2.6.2 Lineare Regression . . . . . . . . . . . . . . . . . . . .
2.6.3 Logistische Regression . . . . . . . . . . . . . . . . . .
2.6.4 Regressions- und Modellbäume . . . . . . . . . . . . .
2.6.5 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . .
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
2.7.2 Der Begriff Clustering . . . . . . . . . . . . . . . . . .
2.7.3 Datentypen in der Cluster-Analsye . . . . . . . . . . .
2.7.4 Berechnung der Abstände . . . . . . . . . . . . . . . .
2.7.5 Kategorien von Clusteringverfahren . . . . . . . . . . .
2.7.6 Algorithmen der Partitionierungsverfahren . . . . . . .
2.7.7 Algorithmen hierarchischer Verfahren . . . . . . . . . .
2.7.8 Algorithmen Dichte-basierter Verfahren . . . . . . . . .
Fallbasiertes Schliessen . . . . . . . . . . . . . . . . . . . . . .
2.8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
2.8.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . .
2.8.3 Fallrepräsentation . . . . . . . . . . . . . . . . . . . . .
2.8.4 Ähnlichkeitsbestimmung . . . . . . . . . . . . . . . . .
2.8.5 Aufgabenklassen für fallbasierte Systeme . . . . . . . .
2.8.6 Bezug zum Projekt ’DIONE’ . . . . . . . . . . . . . . .
2.8.7 Vor- und Nachteile des fallbasierten Schließens . . . . .
Das Softwarepaket SPSS Clementine 7.2 . . . . . . . . . . . .
2.9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
2.9.2 Das CRISP-Datenmodell . . . . . . . . . . . . . . . . .
2.9.3 Die Arbeitsoberfläche von Clementine . . . . . . . . . .
2.9.4 Die einzelnen Knoten . . . . . . . . . . . . . . . . . . .
2.9.5 Expression Builder . . . . . . . . . . . . . . . . . . . .
2.9.6 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9.7 Abkürzungen . . . . . . . . . . . . . . . . . . . . . . .
3 Anforderungsdefinition
3.1 Vorgaben und Ziele . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Web-Applikation innerhalb eines Service-Containers
3.1.2 Entwicklungsumgebung . . . . . . . . . . . . . . . .
3.2 Szenarien und Anwendungsfälle . . . . . . . . . . . . . . .
3.2.1 Akteure . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Wesentliche Anwendungsfälle . . . . . . . . . . . .
3.2.3 Weitere Anwendungsfälle . . . . . . . . . . . . . . .
3.3 Prozessverläufe . . . . . . . . . . . . . . . . . . . . . . . .
iv
.
.
.
.
.
.
.
.
72
73
73
73
77
83
89
91
91
91
91
92
93
95
98
103
105
105
105
107
111
116
117
118
119
119
119
122
122
128
129
133
135
. 135
. 136
. 136
. 136
. 136
. 137
. 138
. 141
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
142
143
144
144
144
144
145
145
145
145
146
146
146
146
147
147
147
147
148
148
149
150
150
150
151
151
151
151
4 Grobentwurf
4.1 Systemaufbau . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Modul Steuerung . . . . . . . . . . . . . . . . . .
4.1.2 Modul WebUserInterface . . . . . . . . . . . . . .
4.1.3 Modul Datamining Algorithmen . . . . . . . . . .
4.1.4 Modul Datenstrukturen . . . . . . . . . . . . . .
4.1.5 Schnittstelle User - WebUserInterface . . . . . . .
4.1.6 Schnittstelle WebUserInterface - Datenstrukturen
4.1.7 Schnittstelle WebUserInterface - Algorithmen . .
4.1.8 Schnittstelle Algorithmen - Datenstrukturen . . .
4.1.9 Kommunikation Steuerung - Algorithmen . . . . .
4.1.10 Kommunikation Steuerung - Datenstrukturen . .
4.1.11 Kommunikation Steuerung - Präsentation . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
153
153
154
155
157
161
164
164
168
170
171
171
172
3.4
3.5
3.6
3.7
3.8
3.3.1 Verfahren . . . . . . . . . . . .
3.3.2 Trait-Matrix . . . . . . . . . . .
3.3.3 Ergebnisvergleich . . . . . . . .
Funktionale Anforderungen . . . . . .
3.4.1 Benutzerverwaltung . . . . . . .
3.4.2 Management der Arbeitsabläufe
3.4.3 Auswahl der Trait-Matrix . . .
3.4.4 Modellerstellung . . . . . . . .
3.4.5 Modellverifizierung . . . . . . .
3.4.6 Modellvorhersage . . . . . . . .
3.4.7 Ergebnisausgabe . . . . . . . .
3.4.8 Jobverwaltung . . . . . . . . . .
Nichtfunktionale Anforderungen . . . .
3.5.1 Latenzzeiten . . . . . . . . . . .
3.5.2 Erweiterbarkeit . . . . . . . . .
3.5.3 Sicherheit . . . . . . . . . . . .
3.5.4 Verfügbarkeit . . . . . . . . . .
3.5.5 Korrektheit . . . . . . . . . . .
3.5.6 Kompatibilität . . . . . . . . .
3.5.7 Haftung . . . . . . . . . . . . .
Systemaufbau . . . . . . . . . . . . . .
3.6.1 Web-Browser . . . . . . . . . .
3.6.2 Kernkomponente . . . . . . . .
3.6.3 Datenbank . . . . . . . . . . . .
Dokumentationsanforderungen . . . . .
3.7.1 Entwicklerdokumentation . . .
3.7.2 Endbenutzerdokumentation . .
Akzeptanzkriterien . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
Inhaltsverzeichnis
4.2
4.1.12 Kommunikation Datenstrukturen - Algorithmen
Ablaufbeschreibung . . . . . . . . . . . . . . . . . . . .
4.2.1 Anwenderauthentifizierung . . . . . . . . . . . .
4.2.2 Experimentauswahl . . . . . . . . . . . . . . . .
4.2.3 Erstellen einer Trait-Matrix . . . . . . . . . . .
4.2.4 Auswahl des Verfahrens und Konfiguration . . .
4.2.5 Start des Verfahrens . . . . . . . . . . . . . . .
4.2.6 Verlauf des Verfahrens . . . . . . . . . . . . . .
5 Feinentwurf
5.1 Paketstruktur . . . . . . . . . . . . . . . . . . . . .
5.1.1 Struktur des Java-Quelltextes . . . . . . . .
5.2 Schnittstellen . . . . . . . . . . . . . . . . . . . . .
5.2.1 Modul Datenstrukturen . . . . . . . . . . .
5.2.2 Modul Algorithmen . . . . . . . . . . . . . .
5.3 Inhaltlicher Aufbau der Webseiten von DIONE . . .
5.4 Serverseitige Stuktur der Webseiten von DIONE . .
5.4.1 Übersicht JSP, Skript-Funktionen und Styles
5.5 Klassen des WUI Moduls . . . . . . . . . . . . . . .
5.5.1 Paket wui.action . . . . . . . . . . . . . . .
5.5.2 Paket wui.lang . . . . . . . . . . . . . . . .
5.5.3 Paket wui.tag.table . . . . . . . . . . . . . .
5.5.4 Paket wui.tag.tree . . . . . . . . . . . . . .
5.5.5 Paket wui.tag . . . . . . . . . . . . . . . . .
5.5.6 Paket wui.util . . . . . . . . . . . . . . . . .
5.6 Klassen des Moduls Steuerung . . . . . . . . . . . .
5.6.1 MiningJob . . . . . . . . . . . . . . . . . . .
5.6.2 MiningJobManager . . . . . . . . . . . . . .
5.6.3 SimpleJobManager . . . . . . . . . . . . . .
5.6.4 DioneException . . . . . . . . . . . . . . . .
5.7 Klassen des Moduls Algorithmen . . . . . . . . . .
5.7.1 Paket algorithm . . . . . . . . . . . . . . . .
5.7.2 Paket algorithm.model . . . . . . . . . . . .
5.7.3 Paket algorithm.model.dione . . . . . . . . .
5.7.4 Paket algorithm.model.xelopes . . . . . . . .
5.7.5 Paket algorithm.model.weka . . . . . . . . .
5.7.6 Paket algorithm.util . . . . . . . . . . . . .
5.7.7 Paket algorithm.visualization . . . . . . . .
5.8 Klassen des Moduls Datenstrukturen . . . . . . . .
5.8.1 WUI-DS . . . . . . . . . . . . . . . . . . . .
5.8.2 Algorithmus Konfiguration . . . . . . . . . .
5.8.3 Traitmatrix . . . . . . . . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
173
173
174
174
174
175
175
175
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
. 177
. 177
. 177
. 178
. 180
. 184
. 191
. 191
. 195
. 195
. 197
. 197
. 198
. 198
. 199
. 201
. 201
. 203
. 204
. 205
. 206
. 206
. 208
. 211
. 211
. 212
. 212
. 213
. 218
. 218
. 221
. 223
Inhaltsverzeichnis
5.9
Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9.1 Tabellenstruktur Experiment . . . . . . . . . . .
5.9.2 Tabellenstruktur Algorithmusspezifikationen . . .
5.10 Ausgewählte Abläufe . . . . . . . . . . . . . . . . . . . .
5.10.1 Interaktiver Entscheidungsbaumalgorithmus . . .
5.10.2 Zusammenspiel von JSP und anderen Elementen .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
230
231
237
246
246
248
6 Umsetzung und Implementation
251
6.1 Unterschiede zum Entwurf . . . . . . . . . . . . . . . . . . . . 251
7 Ausblick
253
7.1 Vorschläge zur Erweiterung . . . . . . . . . . . . . . . . . . . 253
7.2 Bekannte Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Anhang
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . .
Liste der Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . .
Literaturverzeichnis
I
I
V
VII
vii
Inhaltsverzeichnis
viii
Kapitel 1
Einleitung
1.1 Motivation
Heutzutage werden Information und Wissen zunehmend elektronisch gespeichert und aufbereitet. Dabei ist es leicht möglich bei einer großen Menge
von Daten den Überblick zu verlieren. Das führt dazu, dass eine Auswertung der Daten per Hand undenkbar wird. Um diesem Problem zu begegnen
gibt es bereits vielfältige automatisierte Ansätze, zusammen gefasst unter
dem Begriff ”Data-Mining”, um aus diesem Datenüberfluss strukturiertes
aufbereitetes Wissen zu extrahieren. Mit diesem Themenfeld wird sich diese
Projektgruppe beschäftigen.
Diese Projektgruppe ist Teil des LEDA-Projekts das sich mit der, innerhalb dieses Projektes entwickelten, LEDA-Traitbase, einer offenen, europaweiten Datenbank, die Pflanzen-Daten speichert und zur Verfügung stellt,
beschäftigt.
1.2 Ziele
Innerhalb dieser Projektgruppe, die den Namen DIONE trägt, soll nun eine
Plattform geschaffen werden, um auf der vorhandenen LEDA-Traitbase verschiedene Data-Mining-Verfahren anwenden zu können. Dabei soll die Plattform durch eine Internet-Präsenz auf Basis von Webapplikationen erstellt
werden um den Zugriff nicht auf das Vorhandensein eines zu installierenden
Programms zu beschränken. Außerdem sollen für den Datamining-Teil verschiedene Algorithmen integriert werden, und auch die Möglichkeit geschaffen werden zu einem späteren Zeitpunkt andere Verfahren hinzu zufügen
1
Kapitel 1 Einleitung
1.3 Inhalt
Innerhalb dieses Berichtes werden im folgenden zunächst alle Seminarvorträge der Projektteilnehmer zu den in diesem Projekt relevanten Themen
vorgestellt. Im Anschluss folgt die, in der Gruppe erstellte, Anforderungsdefinition. Diese wird dann zunächst im Grobentwurf verfeinert. Hier werden
auch bereits allgemeine Designentscheidungen getroffen. Diese werden dann
im Feinentwurf konkretisiert und es wird dort, unter anderem mit Klassendiagrammen und -beschreibungen, eine Basis für die Implementation geschaffen.
2
Kapitel 2
Grundlagen
In diesem Kapitel werden alle zur Projektarbeit nötigen Grundlagen, die in
Seminarvorträgen vorgestellt wurden, erläutert und zum späteren Nachschlagen zusammengetragen.
Diese Grundlagen beinhalten zunächst einen Überblick über das Projekt LEDA, in dessen Rahmen diese Projektgruppen stattfindet, und die zugehörige
Datenbank. Darauf folgen drei Arbeiten die sich mit den technischen Mitteln
beschäftigen die nötig sind um eine Webapplikation zu erzeugen. In diesen
Arbeiten geht es daher um JSP, Servlets, J2EE, Tomcat und Struts. Was
diese Sachen im einzelnen sind wird in den jeweiligen Arbeiten erklärt. In
den fünf abschließenden Arbeiten geht es um die verschiedenen DataminingVerfahren und deren Funktionsweise und Anwendung. Die letzten beiden
Arbeiten befassen sich mit dem Vergleich der Verfahren und schon vorhandenen Implementationen der Verfahren.
3
Kapitel 2 Grundlagen
2.1 LEDA - Projektübersicht und
Datenbankschema von Richard Hackelbusch
Life history traits of the northwest European flora: a database (LEDA)
Um sich den Herausforderungen stellen zu können, welche sich aus dem Eingriff des Menschen in die Umwelt - z.B. durch hohe Luftverschmutzung durch
Verkehr und Industrie, eine veränderte Landnutzung, die Zerklüftung der
Landschaft durch Siedlungs- und Straßenbau - auf die europäische Flora
ergeben, und um internationalen (UNO-Konferenz für Umwelt und Entwicklung [6]) sowie europäischen (Habitats Directive [2]) Verpflichtungen nachkommen zu können, ist ein hohes Maß an Wissen über die Eigenschaften der
Pflanzen dieser Flora erforderlich. Aus diesem Grund ist das Projekt LEDA Traitbase (im Folgenden LEDA“) ins Leben gerufen worden, welches
”
als Zielsetzung die Schaffung einer Datenbank über die (zunächst nordwest-)
europäische Flora mit über 3000 Pflanzenarten und mit je über 20 Merkmalen hat ( Traitbase“).
”
Dieses von der Europäischen Union über ihren Forschungs- und Entwicklungsdienst CORDIS [3] im fünften Rahmenprogramm geförderte Projekt1
ist auch der Anlass für diese Projektgruppe (Data Mining Workbench für eine ökologische Datenbank ). Für LEDA ist eine Projektdauer von drei Jahren
vorgesehen, welche am 1. November 2002 begonnen hat und am 31. Oktober 2005 endet. Die Koordination des Projekts übernimmt die AG Landschaftsökologie der Universität Oldenburg. Außerdem sind noch zehn Partner
(Universitäten und wissenschaftlichen Institute) am LEDA Projekt beteiligt.
2.1.1 Einleitung
Um die Merkmale von Pflanzen zu erfassen, hat es bereits Bestrebungen
mit teilweise beträchtlichem Aufwand gegeben. Daher ist die Menge der gesammelten Daten schnell gewachsen. Allerdings sind die Daten über viele
Quellen (Datenbanken, Veröffentlichungen, etc) mit unterschiedlicher Größe
verteilt. Die Quellen selbst sind in verschiedenen Sprachen und über die
Länder Europas verteilt gesammelt und gespeichert worden. Es hat bisher
keine Zusammenführung der Daten gegeben. Aus diesem Grund konnte bislang auch noch keine europaweite Funktionsanalyse der Pflanzenmerkmale
und der Auswirkungen des Menschen auf die Flora vorgenommen werden.
Diese Zusammenführung der Daten / Pflanzenmerkmale ( traits“) soll mit
”
1
4
Projektnummer: EVR1-CT-2002-40022
2.1 LEDA - Projektübersicht und Datenbankschema
dem LEDA Projekt vorgenommen werden und damit eine europaweite Datenbank der Pflanzenmerkmale ( Traitbase“) entstehen.
”
Eine wesentliche Herausforderung ist, mit Hilfe dieses Informationssystems
Veränderungen der Flora innerhalb einer sich laufend ändernden Landschaft
vorhersagen zu können. So ist von besonderem Interesse, in wie weit Pflanzen in ihrem vorhanden Lebensraum fortbestehen können, oder ob sie neue
Lebensräume erschließen bzw. kolonisieren können. Diese beiden Fähigkeiten hängen von den biologischen Merkmalen der Pflanzen ab. Es wird vor
theoretischem Hintergrund erwartet, dass die Fähigkeiten eindeutige Funktionskombinationen durch die Merkmale der Pflanzen beschreiben.
Hierzu sollen in der LEDA Datenbank so genannte Sorte-Merkmal-Matrizen“
”
erzeugt werden, welche die verschiedenen Merkmale miteinander in Beziehung setzen.
Dieser Text ist die Seminarausarbeitung zum gleichnamigen Seminarvortrag.
Er geht im Folgenden auf die konkreten Ziele des LEDA-Projekts, die Herangehensweise beim Entwickeln des Systems und als Schwerpunkt auf die Datenqualität und das Datenbankschema, welches zur internen Datenrepräsentation Verwendung finden soll, ein. In Hinblick auf die Zielgruppe wird auf
biologische Details nur am Rande eingegangen.
2.1.2 Ziele
Das Ziel des LEDA Traitbase Projekts ist es, eine offene euroapaweite Datenbank der Pflanzenmerkmale der Flora Europas - beginnend mit der Flora
Nordwesteuropas - zu schaffen, um den Herausforderungen - der durch den
Menschen verursachten Veränderungen der Pflanzenwelt - entgegenzutreten.
Da weder die Flora noch die von den Menschen verursachten Veränderungen an der Flora an nationalen Grenzen halt machen, und um einen Nutzen
aus bereits erhobenen Daten ziehen zu können, sollen dazu verschiedene bereits existierende nationale Datenprojekte und in der Literatur veröffentliche
Daten zusammengefügt werden. Aus diesem Grund hat es sich geradezu angeboten, dieses Projekt im europäischen Rahmen durchzuführen.
Die über 20 Pflanzenmerkmale, die in der LEDA Datenbank gespeichert werden sollen, sind in drei für ein Verständnis der Pflanzen besonders wichtige
Merkmalsklassen eingeteilt:
• Persistence: Daten zur Beschaffenheit und zur Überlebensstärke einer
Pflanze
5
Kapitel 2 Grundlagen
• Regeneration: Daten zum Lebenszyklus und zur Vermehrung der Pflanze
• Dispersability: Daten zur Ausbreitung und Verteilung der Samen der
Pflanze
Um diese Daten in die Datenbank einpflegen zu können, sollen unterschiedliche Quellen verwendet werden: Wie bereits erwähnt, sollen verschiedene
bisher national geführte Datenbankprojekte in LEDA zentralisiert zusammengeführt werden. Daneben soll ein umfangreicher Schatz an LiteraturVeröffentlichungen, deren Erscheinung teilweise bis ins 19. Jahrhundert zurückreicht, in den Datenbestand eingepflegt werden. Das gilt auch für bisher
unveröffentliche Datenerhebungen sowie für Messungen, welche extra für LEDA vorgenommen werden. Hieraus erhofft man sich die Verfügbarkeit eines
Datenbestandes von mehr als 20 Pflanzenmerkmalen von über 3000 Pflanzenarten der Flora Nordwesteuropas.
Dieser Datenbestand soll über ein WWW-Interface verfügbar gemacht werden. Die Schnittstelle soll Funktionen zur Dateneingabe, der Anzeige der Daten in der Datenbank, der Anzeige von Metadaten, sowie der Analyse der Daten mit Data-Mining-Werkezugen anbieten. Um die Nutzbarkeit der LEDA
Traitbase zu demonstrieren, ist vorgesehen, in die WWW-Schnittstelle spezielle Werkzeuge zur Analyse verschiedener europäischer Regionen zu integrieren. Desweiteren soll das LEDA-System eine Plattform zum wissenschaftlichen Austausch anbieten, um unnötige Mehrfacheingaben zu verhindern und
internationale Kenntnis von Funktionsbedeutung von Pflanzenmerkmalen zu
bündeln.
Die erwarteten Nutzergruppen umfassen das gesamte Spektrum an Personen, die ein Interesse an der (Nutzung der) Flora Europas haben. Sie gehen
von Landschaftsplanern, Landwirten über Politikberater, Politiker, Entscheidungsträger bis hin zu Wissenschaftlern.
2.1.3 Herangehensweise
Die zu erledigende Arbeit für LEDA ist in fünf so genannte Workpackages
aufgeteilt worden. Dabei fallen die ersten drei Workpackages für die Sammlung bzw. das Einpflegen der Daten an, wobei die Aufteilung der Arbeit
dafür nicht nach Regionen oder Pflanzanarten erfolgt, sondern in die drei
oben bereits beschriebenen Pflanzenmerkmalsklassen Persistence, Regeneration sowie Dispersability.
6
2.1 LEDA - Projektübersicht und Datenbankschema
Das vierte Workpackage befasst sich mit dem Entwurf und der Implementierung des dafür benötigten Informationssystems, welches die Daten speichert,
Schnittstellen zur Ein- und Ausgabe der Daten über das Internet bereitstellt,
sowie Data-Mining und Data-Retrieval Anwendungen beinhaltet.
Im fünften Workpackage schließlich werden Beispielanwendungen speziell für
die einzelnen - bereits oben erwähnten - erwarteten Benutzergruppen von
LEDA zur Demonstration ihrer Leistungsfähigkeit entwickelt.
Die Projektgruppe Data Mining Workbench für eine ökologische Datenbank
ist somit dem vierten Workpackage zuzuordnen; sie soll Data-Mining Tools
für LEDA entwerfen und implementieren.
Die Herangehensweise ist in Abbildung 2.1.3 schematisch abgebildet.
• Workpackage 1: Sorte-Merkmal-Matrix Persistence
- Prof. Dr. Michael Kleyer, Universität Oldenburg
• Workpackage 2: Sorte-Merkmal-Matrix Regeneration
- Prof. Dr. Jan Bakker, Universität Groningen
• Workpackage 3: Sorte-Merkmal-Matrix Dispersability
- Dr. Ken Thompson, Universität Sheffield
• Workpackage 4: Informationssystem
- Prof. Dr. Michael Sonnenschein, Universität Oldenburg / OFFIS
• Workpackage 5: Beispielanwendungen
- Prof. Dr. Peter Poschlod, Universität Regensburg
2.1.4 LEDA Datenstandards
Nachdem es in den vorherigen Abschnitten eine Übersicht über das LEDA
Traitbase Projekt gegeben hat, befasst sich dieser Abschnitt mit dem Thema
der internen Repräsentation der gesammelten Pflanzenmerkmale und übrigen
Daten innerhalb der Datenbank, die für die Arbeit dieser Projektgruppe
von sehr hoher Bedeutung ist. Zunächst wird auf die Datenstandards und
die Ansprüche an die Datenqualität seitens LEDA eingegangen, worauf eine
Vorstellung ihrer Umsetzung als Datenbankschema folgt.
LEDA Datenstandards aus inhaltlicher Sicht
Da aus biologischer Sicht ein hohes Qualitätsniveau der Daten angestrebt
wird, soll für jedes Pflanzenmerkmal eine bestimmte Datenstruktur eingehalten werden. Dabei gilt der Grundsatz, dass der Detailgrad möglichst hoch
7
Kapitel 2 Grundlagen
WP 1, 2, 3
LEDA data collection
WP 1
Persistence
WP 2
Regeneration
WP 3
Dispersal
WP 4
LEDA database system
WWW access
user friendly input
interface
Data retreival tool
Data mining tool
e-networking
plattform
WP 5
LEDA application for end-users
National
Landscape
Habitat
policy
consultant
environmental
planner
restoration
manager
farmer
tutorial
Abbildung 2.1: Schematische Darstellung der Herangehensweise mit den fünf
Workpackages
sein soll. Er wird damit begründet, dass den daraus erwachsenen Vorteilen
aufgrund der Verfügbarkeit von moderner Hard- und Software keine nennenswerten Nachteile entgegenstehen, da moderne Informationssysteme in
der Lage sind, auch mit sehr großen Datenbeständen umzugehen. Die Informationen eines Merkmals müssen dafür in das verwendete Datenbankschema
abgeleitet werden.
Es soll innerhalb einer Datenstruktur neben den obligatorischen immer auszufüllenden Datenfeldern auch optionale Felder geben, deren Ausfüllung nicht
vorgeschrieben ist. Dies ist auch nicht immer möglich, da manche Quellen
aus der Literatur vielleicht gar keine entsprechenden Daten vorhalten.
Die Attribute der Pflanzenmerkmale lassen sich in zwei Kategorien aufteilen:
Es gibt qualitative und quantitative Merkmale. Bei quantitativen Merkmalen
genügt die Angabe eines bestimmten (nicht zwangsläufig numerischen) Wertes, welcher z.B. die Zugehörigkeit zu einer Merkmalsklasse beschreibt. Man
unterscheidet bei qualitativen Merkmalen zwischen ordinalen (Ausprägungen
können geordnet werden, z.B. Größenklasse) und nominalen (Ausprägungen
lassen sich nicht ordnen, z.B. Zugehörigkeit zu einer Pflanzenfamilie) Merkmalen. Für quantitative (numerische) Merkmale werden dagegen mehrere Attribute wie z.B. der Durchschnitt, der Median, das Minimum, das Maximum
oder die Varianz bereitgestellt. Bei quantitativen Merkmalen unterscheidet
man zwischen diskreten (zählbaren) und stetigen Merkmalen.
Ebenso wird gefordert, dass die Daten in atomarer Form in die Datenbank
8
2.1 LEDA - Projektübersicht und Datenbankschema
eingetragen werden. Das bedeutet, dass es in der Datenbank z.B. für das
Merkmal PH-Wert des Wassers“ kein Feld PH-Wert“ gibt, in welches die
”
”
Zeichenkette 2.5 <= PH <= 3.5“ eingetragen werden kann, sondern, da es
”
sich bei dem Merkmal um ein quantitatives Merkmal handelt, Felder für
Minimum und Maximum vorhanden sein sollen. Außerdem soll bei quantitativen Merkmalen auf eine Klassifizierung vor der Eingabe verzichtet werden.
Wenn z.B. der PH-Wert des Wassers 2.5 ist, und damit einer Klasse klein“
”
angehört, soll trotzdem der Wert 2.5“ in der Datenbank gespeichert wer”
den. Auf diese Weise kann eine Klassifizierung seitens der Datenbank im
Nachhinein vorgenommen werden, und es entsteht kein Informationsverlust
bei nachträglicher Änderung der Klassen.
LEDA Datenstandards aus entwurfsorientierter Sicht
Die Umsetzung der geforderten Datenstandards und Datenqualität erfolgt
durch den Einsatz einer relationalen Datenbank. Das Schema besteht daher aus Entitätstypen, welche durch Relationen miteinander verknüpft sein
können. Die graphische Repräsentation des Schemas erfolgt durch ein EntityRelationship-Diagramm. Darin werden Entitätstypen durch Kästen und Relationen durch Rauten und Linien dargestellt.
Auch aus Sicht der Informatik wird ein hohes Maß an Qualität von den Daten gefordert. Dies kann durch den Aufbau des Datenbankschemas realisiert
werden. Glücklicherweise korreliert der Anspruch positiv mit den Qualitätsanforderungen, welche im vorherigen Abschnitt beschrieben worden sind. Um
ganz allgemein ein hohes Maß an Datenqualität zu erhalten, wird angestrebt,
dass das Datenbankschema eine möglichst hohe (d.h. mindestens die dritte)
Normalform erfüllt (vgl. [8]).
Damit ein Schema die erste Normalform erfüllt, reicht es, dass jedes Attribut jedes Entitätstyps atomar sein muss. Schon durch die Erfüllung der
ersten Normalform wird das Schema einigen Qualitätsansprüchen aus dem
vorigen Abschnitt gerecht (nur die Eingabe von atomaren Werten gestatten).
Durch das geschickte Organisieren von Entitätstypen, ihrer Schlüsselattribute und Fremdschlüsselbeziehungen soll das Schema möglichst auch höheren
Normalformen entsprechen. Damit soll verhindert werden, dass Redundanz
und Anomalien (Einfüge-, Lösch- bzw. Aktualisierungsanomalie) auftreten.
Um auch den anderen Qualitätsansprüchen gerecht zu werden, ist die Entscheidung dafür gefallen, jedes Pflanzenmerkmal mit einem eigenen Entitätstyp zu modellieren. Alle Attribute eines Merkmals sind auch gleichzeitig Attribut des entsprechenden Entitätstyps. Dabei stehen für quantitative Merkmale je ein Attribut für die durchschnittliche Größe, den Median, das Mini-
9
Kapitel 2 Grundlagen
mum, das Maximum, die Varianz und den Standardfehler bereit. Quantitative Merkmale erhalten meist Attribute, welche als Fremdschlüsselbeziehung
mit Entitätstypen über eine Relation verbunden sind, die die entsprechenden
quantitativen Werte beinhalten. Ebenso werden andere wichtige Informationen wie z.B. die Klassifizierung der Pflanze oder die Quellenangabe als eigene
Entitätstypen organisiert.
Als Beispiel für die Repräsentation - bevor ein Überblick über das gesamte Datenbankschema erfolgt - soll die Datenstruktur eine Literaturreferenz
als Datenquelle für Pflanzendaten dienen. Zunächst erfolgt ein Ausschnitt
einer tabellarischen Beschreibung der zu speichernden Daten, worauf im Anschluss die Umsetzung als Entity-Relationship-Diagramm (ER-Diagramm)
visualisiert wird (vgl. Abbildung 2.2 und Tabelle 2.1, sowie [4]).
Attribut
Refname
Reftype
Author
Year
Publisher
ISXN
Beschreibung
Verkürzter Name der Datenquelle
Person, Veröffentlichung oder Datenbank
Liste von Autorennamen – separat gespeichert
Jahr der Veröffentlichung
Name des Verlegers
ISSN oder ISBN-Nummer der Quelle
Format
Text
Text
Text
Number
Text
Number
Level
Optional
Obligatorisch
Obligatorisch
Obligatorisch
Obligatorisch
Optional
Tabelle 2.1: Literaturquellen in der Datenbank
Abbildung 2.2: Literaturquellen in der Datenbank
Wie man sehen kann, ist für die Repräsentation einer Veröffentlichung der
Entitätstyp Publication“ vorgesehen. Er hat den Primärschlüssel (ober”
halb der horizontalen Linie innerhalb des Entitätstyps) referenceID(FK)“,
”
10
2.1 LEDA - Projektübersicht und Datenbankschema
welcher eine Spezialisierungsrelation auf den Primärschlüssel des Entitätstyps Reference“ (leider nicht mehr im Bild) ist. Attribute wie Jahr der
”
Veröffentlichung ( Year“) oder Titel der Veröffentlichung ( Title“) sind kei”
”
ne Fremdschlüsselbeziehungen und werden direkt in dem Entitätstyp gespeichert. Attribute, die Fremdschlüssel zu anderen Entitätstypen sind, werden in der vorliegenden Entity-Relationship Repräsentation mit (FK)“ ge”
kennzeichnet. In diesem Beispiel sind das neben dem schon angesprochenen Primärschlüssel referenceID“ die Attribute languageCode“, journa”
”
”
lID“ sowie pubtypeID“. Die Informationen über den Autor werden eben”
falls nicht in dem Entitätstyp Publication“ gespeichert. Nur hat man sich
”
in diesem Fall dazu entschieden, das Attribut, das auf die Verbindung von
Autor und Veröffentlichung hinweist, als eigenen Entitätstyp Authorship“
”
zu realisieren.
Diese Verknüpfungen der Entitätstypen über Fremdschlüsselbeziehungen dienen dazu, die bereits erwähnten Anomalien sowie unnötige Redundanz zu
vermeiden. Auf diese Weise können z.B. alle für eine Sprache relevanten Daten in dem Entitätstyp LanguageCode“ gespeichert werden, und, sollte es
”
zu Änderungen daran kommen, müssten diese Änderungen nur innerhalb
dieses Entitätstyps vorgenommen werden.
Abbildung 2.3: Übersicht über das LEDA Datenbankschema
Wie zu erkennen ist, haben die einzelnen Entitätstypen im ER-Diagramm
unterschiedliche Hintergrundfarben. Diese dienen dazu, leichte Unterscheidungen bezüglich des Zwecks bzw. der Funktion eines Entitätstyps vornehmen zu können. Dies ist gerade dann nützlich, wenn das ER-Diagramm - wie
11
Kapitel 2 Grundlagen
im Fall von LEDA - sehr umfangreich geworden ist.
Abbildung 2.3 zeigt eine Übersicht über das Schema, welches für LEDA zum
Einsatz kommt (vgl. [4]). Dieses ER-Diagramm ist freilich vollständig, jedoch leidet leider die Übersichtlichkeit unter dieser Vollständigkeit. Es ist
zwar versucht worden, Entitätstypen, welche inhaltlich miteinander in Beziehung stehen, räumlich möglichst nah aneinander anzuordnen, jedoch ist
es in dem Diagramm nicht mehr möglich, die relationalen Beziehungen zwischen allen Entitätstypen nachzuvollziehen. Es überdecken sich einfach zu
viele als Verbindungslinie dargestellte Relationen.
Abbildung 2.4: Übersicht über das LEDA Datenbankschema - Einteilung in
Regionen
Um sich dennoch einen Überblick über den Aufbau des Datenbankschemas
verschaffen zu können, habe ich das ER-Diagramm in vier Teilbereiche aufgeteilt (vgl. Abbildung 2.4), welche im folgenden vorgestellt werden.
Abbildung 2.5 zeigt den Ausschnitt a aus Abbildung 2.4 in vergrößerter
Form. In diesem Teilbereich des ER-Schemas befinden sich die Entitätstypen für alle Daten mit Ausnahme der Pflanzenmerkmale und Lebensräume
der Pflanzen. Dabei sind die dort abgespeicherten Daten drei Hauptfunktionen zuzuordnen:
Die grün unterlegten Entitätstypen ( LedaUser“, etc) betreffen die Daten
”
bezüglich des Nutzers der LEDA Datenbank. Über ihn werden die Daten
abgespeichert, welche zur Nutzung der Datenbank nötig sind (Username,
Passwort) sowie einige persönliche Daten wie z.B. die EMail-Adresse. Daneben werden über ihn die Daten abgespeichert, die bestimmen, zu welcher
12
2.1 LEDA - Projektübersicht und Datenbankschema
Abbildung 2.5: Entitätstypen ohne die Pflanzenmerkmale
13
Kapitel 2 Grundlagen
Benutzergruppe der Benutzer gehört, und welche Rolle er im LEDA Projekt
einnimmt.
Abbildung 2.6: Entitätstypen zu Pflanzenfundort und Lebensraum
Die gelb unterlegten Entitätstypen ( Reference“, etc) wurden bereits weiter
”
oben angesprochen: Hiermit können Daten über die Herkunft einer Pflanzeninformation abgespeichert werden. So kann eine solche Quelle eine bereits
existierende Datenbank oder aber auch eine Literaturveröffentlichung sein.
In den türkis unterlegten Entitätstypen ( Taxon“, etc) wird schließlich die
”
Pflanze selber klassifiziert und abgespeichert. So zählen dazu Attribute wie
Name der Pflanze, Spezies der Pflanze, usw.
Auffällig sind des Weiteren noch violett hinterlegte Entitätstypen. Diesen
Entitätstypen ist allerdings keine gemeinsame inhaltliche Bedeutung zuzuordnen. Sie beinhalten vielmehr Informationen zu verschiedenen Klassifizierungen. Diese logical-value-Relationen haben den Zweck, flexibel auf Umbenennungen von Kategorien oder Klassen reagieren zu können. Sie finden
sich auch in den anderen Abschnitten des ER-Diagramms wieder, die im
Folgenden beschrieben werden.
Abbildung 2.6 zeigt den Ausschnitt b aus Abbildung 2.4 in vergrößerter
Form. Innerhalb dieses Abschnittes befinden sich Entitätstypen, die Daten
bezüglich des Lebensraums ( HabitatType“) und des Fundortes der Pflan”
zenpopulation ( GeoReference“) beinhalten sollen.
”
14
2.1 LEDA - Projektübersicht und Datenbankschema
Bezüglich des Lebensraums der Pflanzenpopulation werden dann Daten wie
der PH-Wert bzw. Säuregehalt des Wassers und des Bodens gespeichert.
Für den Fundort der Pflanzenpopulation werden Attribute für Daten wie das
Land, in dem die Pflanzenpopulation wächst, bereitgestellt.
Außerdem beinhaltet dieser Abschnitt des ER-Diagramms noch der Entitätstyp der Relation Picture“, welche die Möglichkeit gibt, ein Bild einer Pflanze
”
der Population in der Datenbank abzuspeichern.
In den Abschnitten c und d von Abbildung 2.4 befinden sich die Entitätstypen für die Speicherung der über 20 einzelnen Pflanzenmerkmale. Wie bereits
erwähnt, wird pro Pflanzenmerkmal ein Entitätstyp bereitgestellt. Auffällig
ist allerdings, dass es innerhalb des ER-Diagramms keine räumliche Trennung der Merkmale bezüglich der bereits weiter oben angesprochenen und
in Workpackages eingeteilte Merkmalsklassen Persistence, Regeneration und
Dispersability gibt. Sie sind im Gegenteil innerhalb der Abschnitte c und d
bunt verteilt.
Für die Ausprägung eines Pflanzenmerkmals wird für jedes Merkmal u.a. der
Messwert (die Messwerte bei quantitativen Merkmalen), ein Kommentar, die
Datenquelle (über Fremdschlüsselbeziehung), das Einpflegedatum, die Messmethode (über Fremdschlüsselbeziehung) und Pflanzenklassifizierung (über
Fremdschlüsselbeziehung) abgespeichert. Abbildung 2.7 zeigt dies beispielhaft für das Pflanzenmerkmal Alter der Pflanze beim ersten Blüten“.
”
Abbildung 2.7: Beispiel für einen Entitätstyp eines Pflanzenmerkmals
Für eine detailliertere Information zu dem Datenbankschema sei auf [4] verwiesen. An der Stelle wird das ganze Schema in Form des bereits bekannten
ER-Diagramms gezeigt. Es bietet interaktive Informationen zu Entitätstypen
15
Kapitel 2 Grundlagen
und deren Attributen an, da nach Mausklick auf z.B. ein Attribut in einem
anderen Frame der Webseite eine genaue Beschreibung dazu angezeigt wird.
Weitere Informationsquellen über das LEDA-Projekt sind einmal die LEDA Projekt-Homepage selber (vgl. [5]), sowie das Paper [19], welches einen
verknappten Überblick über das LEDA Projekt gibt und das Paper [14], welches deutlich detaillierter auf Einzelaspekte - gerade auf die zu erfassenden
Pflanzenmerkmale und die dazugehörigen Messmethoden - eingeht.
16
2.2 J2EE, Servlets und JSP
2.2 J2EE, Servlets und JSP von Pascal Kuhn
2.2.1 J2EE
Definition
Java 2 Platform, Enterprise Edition, ist ein Standard, um mit modularen
Komponenten verteilte, mehrschichtige Anwendungen zu entwickeln. J2EE
setzt auf bereits etablierte Standards wie z.B. JDBC oder CORBA auf und
ermöglicht dem Entwickler den Zugriff auf weitere Funktionalitäten wie z.B.
Enterprise Java Beans, Java Servlets, JSP und XML [7] .
Entstehung
Anfang 1999 wurde das Java Development Kit in Java-2-Plattform umbenannt. Um verschiedene Einsatzgebiete von Java deutlicher voneinander abzugrenzen, fasste Sun seine Bibliotheken zu drei Gruppen zusammen:
• Java-2-Plattform, Standard Edition (J2SE), die klassische Java-2-Plattform für Desktop-Anwendungen,
• Java-2-Plattform, Enterprise Edition (J2EE) für große, verteilte Unternehmensanwendungen und
• Java-2-Plattform, Micro Edition (J2ME) für mobile und eingebettete
Systeme (PDAs, Mobiltelefone, Set-Top-Boxen usw.).
Kernelement ist die J2SE, die von J2EE erweitert und von J2ME auf einen
Teilumfang reduziert ist [21] .
J2EE Plattformübersicht
Architektur Die in Abbildung 2.8 dargestellten Zusammenhänge zwischen
den einzelnen Komponenten der J2EE, müssen von jeder J2EE-Plattform
erfüllt werden. Grafik1 liefert hierzu einen logischen Überblick. Die verschiedene Rechtecke stellen die verschiedenen Container dar, die eine Laufzeitumgebung für die jeweils im oberen Teil der Rechtecke aufgezeigten Applikationskomponenten bieten. Die vom jeweiligen Container angebotenen Dienste
sind im unteren Teil der Rechtecke dargestellt. Die Pfeile stellen die benötigte
Mindestkonektivität zwischen den Komponenten an.
17
Kapitel 2 Grundlagen
Applikationskomponenten Eine J2EE Laufzeitumgebung definiert vier verschiedene Applikationskomponenten, die von jedem J2EE Produkt unterstützt
werden müssen [1] :
Applikationen sind Javaprogramme, die normalerweise auf einem Desktopcomputer ablaufen und eine Grafische Benutzerschnittstelle bieten. Sie
bieten eine spezielle Funktionalität und können sehr umfangreich sein.
Servlets, JSP laufen typischerweise in einem Webcontainer ab und reagieren auf HTTP-Anfragen. Servlets und vor allem JSP-Seiten dienen dazu HTML-Seiten zu generieren. Webapplikationen bilden sich aus dem
Zusammenspiel mehrerer dieser Webkomponenten.
Enterprise Java Beans laufen in einer speziell verwalteten Umgebung ab,
die Transaktionen unterstützt. Sie bieten typischerweise die Geschäftslogik einer J2EE-Anwendung
Applets sind kleine Javaprogramme die eine Grafische Oberfläche bieten,
und normalerweise in einem web browser ablaufen. Sie bieten z.B.
ein leistungsfähiges Benutzerinterface auf der Clientseite einer J2EEAnwendung.
Container Container müssen eine Java kompatible Laufzeitumgebung zur
Verfügung stellen, wie sie in Java 2 Plattform Standard Edition definiert ist.
Container bieten den Applikationskomponenten eine federated view der darunterliegenden J2EE APIs. Applikationskomponenten kommunizieren nicht
direkt miteinander, sondern sie nutzen die vom Container zu Verfügung gestellten Protokolle und Methoden um miteinander oder mit externen Komponenten zu kommunizieren. Typische J2EE Produkte bieten für jeden Typ
von Applikationskomponenten je einen Container. Es ist vorgegeben das ein
Container einen bestimmten Satz an Standarddiensten bieten, die im folgenden noch erläutert werden.
Standarddienste Folgende Standarddienste müssen von einem J2EE Server angeboten werden:
HTTP, HTTPS Die HTTP client-side API wird durch das package java.net
definiert, während die server-side API durch die Servlet- und JSP interfaces definiert werden. Für HTTPS gilt das gleiche nur das das HTTPProtokoll über das SSL Protokoll genutzt wird.
18
2.2 J2EE, Servlets und JSP
Java Transaktion API/Service (JTA/JTS) Unterstützen die Abwicklung
verteilter Transaktionen nach dem XA/Open-Standard.
RMI-IIOP Das RMI-IIOP Teilsystem ist zusammengesetzt aus APIs die es
erlauben im RMI Stil zu programmieren, unabhängig vom darunterliegenden Protokoll und aus Implementierungen solcher APIs die sowohl
das ”J2SE native RMI protocol” als auch das CORBA IIOP Protokoll
unterstützen. J2EE Applikationen können diese Protokolle nutzen um
z.B. CORBA- Dienste zu benutzen die außerhalb ein J2EE Systems
ablaufen. Der Zugriff auf Enterprise Java Beans kann ebenfalls über
RMI-IIOP APIs geregelt werden [1].
Java IDL Die Java Interface Definition Language (IDL) bietet J2EE Applikationen die Möglichkeit Externe CORBA- Objekte zu über das IIOPProtokoll anzurufen und mit ihnen zu interagieren.
JDBC API Die Java Database Connectivity stellt eine Programmierschnittstelle zur Verfügung, die den Zugriff auf alle wichtigen relationalen und
Objektrelationalen Datenbanken erlaubt. JDBC definiert eine generische Programmierschnittstelle für Datenbanken als Menge von Klassen und Schnittstellen die, die von einem JDBC-Treiber implementiert
werden müssen. JDBC deckt den gesamten Prozess des Datenbankzugriffs von der Verbindungsherstellung über die Generierung von SQLAbfragen und -Updates bis hin zum Transaktionsmanagements ab [21] .
Java Message Service (JMS) Java Message Service ist ein API für den Zugriff auf Nachrichtenorientierte Systeme, wie z.B. MQSeries von IBM,
die eine asynchrone Kommunikation über den Austausch von Nachrichten benutzen.
Java Naming an Directory Interface (JNDI) Ist eine Umfangreiche Klassenbibliothek für die Nutzung von Namens- und Verzeichnisdiensten.
Mit diesen Diensten kann man Netzwerkressourcen auf Namensräume
abbilden und so einen Transparenten Zugriff auf verteilte Dienste und
Objekte im Netz erhalten.
JavaMail Das JavaMail- API modelliert ein abstraktes Mail-System, das
weitgehend unabhängig von der verwendeten Mail-Middelware ist. Mit
diesem APIs können Mail-Server und Clients auf Basis diverser Protokolle wie SMTP, POP3 und IMAP4 aufgebaut werden [21] .
Java API für XML Parsing Da XML im Datenaustausch eine immer größere Rolle spielt wurde mit JAXP in J2EE eine umfangreiche Programmierschnittstelle für den Zugriff auf XML-Parser und XML- Dokumente mittels SAX und DOM geschaffen. Für formatierte Dokumente
19
Kapitel 2 Grundlagen
steht außerdem eine Unterstützung von XSLT- Transformationen zur
Verfügung.
J2EE Connector Architecture Definiert eine Integrationsschnittstelle, mit
der unterschiedliche Informationsquellen an einen Applikationsserver
gekoppelt werden können. So muss evtl. in einem Unternehmen ein altes Verwaltungssystem integriert werden, da ein ersetzen nicht möglich
ist, oder ein inkompatibles Datenbanksystem soll angeschlossen werden
JCA bietet hier die Lösung, ähnlich wie bei JDBC können die Hersteller oder Drittanbieter der alten Systeme einen Treiber erstellen, der
den Zugriff auf diese Systeme möglich macht.
Security Services Mit dem JAAS-Framework bietet Java ein Rahmenwerk
für die Zugriffskontrolle von Ressourcen und für die Authentifizierung
von Benutzern.
Web Services J2EE bietet volle Unterstützung für einerseits clients von Internetdiensten als auch Internetdienst Endpunkte. Verschiedene Java
Technologien werden kombiniert eingesetzt um eine gute Unterstützung
von Internetdiensten zur Verfügung zu stellen. Die Java API für XMLbasierende RPC (JAX-RPC) bieten Unterstützung für Internetdienste
die ein SOAP/HTTP Protokoll nutzen. JAX-RPC definiert die Abbildung zwischen Java-Klassen und XML wie es von SOAP RPC Aufrufen
verwendet wird.
Management Die Java 2 Plattform, Enterprise Edition Management Spezifikation definiert APIs um J2EE Server mit Hilfe einer speziellen Management Enterprise bean. Desweiteren ist die Java Management Extensions (JMX) API genutzt um weitere Managementfunktionen zur
Verfügung zu stellen.
Schichtenmodell
Moderne Applikationen, insbesondere Webapplikationen, bestehen in der
Regel aus mehreren Schichten, die zusammengesetzt die gesamte Funktionalität bieten. Grundsätzlich wird bei J2EE in vier verschiedene Schichten unterschieden: Clientenschicht, Server-side-Präsentationsschicht, Serverside-Geschäftslogik und die Ressourcenschicht. Die Clientenschicht setzt sich
zusammen aus entweder einer einfachen Browser-HTML-Oberfläche, die evtl.
mit Java-Applets unterstützt wird, oder aus Applikationen, die auf Serverfunktionalitäten zugreifen. Die Server-side-Präsentationsschicht besteht üblicherweise aus Servlets und JSP Elementen, die dynamische Inhalte wie etwa
20
2.2 J2EE, Servlets und JSP
HTML-Seiten generieren, und so eine mächtige Benutzerschnittstelle auf Serverseite bieten. Bei J2EE setzt sich die Geschäftslogik auf Serverseite aus Java Enterprise Beans in Kombination mit Servlets zusammen. JEB kapseln die
Geschäftslogik und sind so leicht portierbar. Alternativ kann die Geschäftslogik auch einfach aus dem Zusammenspiel von Servlets und JSP-Seiten gebildet werden. Die Ressourcenschicht bilden Datenbanken, die für moderne
Softwaresysteme unabdingbar geworden sind. Ebenfalls gehören Verbindungen zu anderen evtl. älteren Systemen z.B. über ein CORBA-Schnittstelle. Es
gibt natürlich auch Softwaresysteme denen weniger Schichten genügen, oder
aber Systeme die weitere Schichten einschieben. Vorteile sind in jedem Fall
aber die bessere Wiederverwendbarkeit, eine leichtere Modulare Entwicklung
sowie eine bessere Erweiterbarkeit.
Sicherheit in J2EE
Sicherheit ist für heutige Softwaresysteme ein sehr wichtiger Faktor. Besonders seit das Internet eine wichtige Ressource für den Austausch von Daten
und dem weltweiten Zugriff auf eben diese bietet, muss Sicherheit auf diversen Gebieten gewährleistet werden. J2EE definiert einen Katalog an minimalen Sicherheitsfunktionen die eine J2EE Anwendung bieten muss. Die wichtigsten dieser Sicherheitsfunktionen sind Authentifizierung, Zugriffskontrolle
auf Ressourcen, Datenintegrität, Datenschutz, Eindeutige Identifizierbarkeit
des Benutzers und ein sichere Log-Funktion.
Die Authentifizierung wird in J2EE so aufgefasst das sich Client und Server einander beweisen müssen das sie berechtigt sind in der benutzen Weise
aufeinander zuzugreifen. So muss z.B. ein client-applet evtl. über ein vom Benutzer eingegebenes Passwort beweisen das der Benutzer das Recht hat mit
diesem applet auf das System zuzugreifen. Wenn ja kann ein Zugriff erlaubt
werden, wenn nicht wird der Zugriff verweigert. Die Zugriffskontrolle auf Ressourcen ist ebenfalls eine wichtige Funktion um zu verhindern das Applikationen oder Clients (Browser oder Applets), auf Hintergrundresourcen zugreifen
auf die sie in ihrer Benutzerrolle nicht befugt sind. Jeder Benutzer bekommt
über seine Anmeldung eine gewisse Befugnis, die normalerweise mit Rollen
verknüpft ist. Benutzer in gleichen Benutzergruppen haben gleiche Rechte.
Aus Gründen der Gewährleistung von Integrität und Datenschutz können
solche Rollen auch bestimmten Programmen oder Komponenten zugewiesen
werden. So kann einiges Komponenten z.B. untersagt werden direkt auf die
Datenbank zuzugreifen, sondern eine vorgegebene Schnittstelle zu benutzen.
In diesem Zusammenhang ist auch der Datenschutz ein wichtiger Aspekt.
Geschützte Daten dürfen nur von Benutzern abgerufen werden können die
auch die nötigen Rechte dazu haben. In der heutigen Informationsgesellschaft
21
Kapitel 2 Grundlagen
stellen Informationen ein wertvolles Gut dar. Daten müssen aus Unternehmerischen Gründen geschützt werden, aber auch um die Privatsphäre von
Privatpersonen zu sichern. Die eindeutige Identifizierbarkeit der auf das System zugreifenden Benutzer ist eine wichtige Sicherheitskomponente, nur so
können Zugriffe zurückverfolgt werden. Wenn jeder Zugriff zuverlässig und
eindeutig zurückverfolgt werden kann, und eine sicheres Logging gewährleistet ist, so ist eine gute Basis für eine sicheres Arbeiten geschaffen. Ein
letztes Konzept ist die Gewährleistung von Datenintegrität. Dies bedeutet
das sichergestellt werden muss das Daten auf ihrem Weg von A nach B nicht
modifiziert werden können. Solche veränderten Nachrichten, z.B. in einem
offenen Netzwerk müssen erkannt werden können.
J2EE bietet für diese Sicherheitskonzepte bereits eine große Zahl an vordefinierte Bibliotheken. Insgesamt ist der Sicherheit eine bedeutende Rolle
zuzuweisen. Ein Unternehmen hat hohe Anforderungen an ein Softwaresystem, insbesondere wenn es sich um Webapplikationen handelt. Java bietet
bereits Grundsätzlich gute Konzepte zum Thema Sicherheit, so kann das
Java Sandbox Modell bereits eine gute Grundsicherheit für das System auf
dem die Applikation laufen soll bieten.
Anwendungsgebiete und Vorteile
J2EE wurde geschaffen um große, verteilte Unternehmensanwendungen zu
erstellen. Im Gegensatz zu J2SE ist J2EE um diverse Komponenten wie
Dienste und andere Grundfunktionalitäten erweitert. Die Grundlage einer
J2EE bildet der J2EE-Server, an den per Spezifikation wichtige Anforderungen gestellt sind. Diese Anforderungen stellen eine gewisse Basis zur
Verfügung, die eine Portierbarkeit von Applikationen ermöglicht. Auch an
J2EE- Anwendungen werden fest definierte Anforderungen gestellt, um eine
gewisse Qualität zu sichern. Die Qualitätssicherung durch das Aufstellen von
konsequenten Regeln ist eine der Grundlagen von J2EE. Durch das Vererbungskonzept in Java kann eine gewisse Grundlage geschaffen werden um
eine Struktur vorzugeben die eingehalten werden muss. J2EE bietet dem
Entwickler viele Vorteile. Grundsätzlich ist Java als Grundlage als Vorteil
zu betrachten. Plattformunabhängigkeit, Objektorientierung, umfangreiche
Bibliotheken sowie ausgereifte Sicherheitsaspekten sind einige der daraus resultierenden Vorteile. Speziell J2EE bietet jedoch dem Entwickler von großen
Verteilten Anwendungen, insbesondere Webapplikationen besondere Vorteile.
Erweiterbarkeit, Skalierbarkeit und Zuverlässigkeit sind hier zentrale Faktoren [20] . Ein bestehendes System muss in der heutigen Zeit, um dauerhaft
22
2.2 J2EE, Servlets und JSP
Leistungsfähig zu bleiben und den immer schneller steigenden Anforderungen
zu genügen, eine gute Erweiterbarkeit bieten. Erweiterbarkeit in diesem Sinne bedeutet, das sich das Softwaresystem leicht ändern, an besondere Gegebenheiten anpassen und um zusätzlichen Funktionsumfang erweitern lassen
kann. Weitere Aspekte der Erweiterbarkeit sind die Wiederverwendbarkeit
und die Modularisierung. Applikationen bestehen in der Regel aus vielen
Modulen, die jeweils Teilfunktionen implementieren. Durch dieses Konzept
ist das auskoppeln und zentralisieren von Teilfunktionen leicht möglich ist,
was insbesondere für das anpassen und erweitern von Softwaresystemen sehr
wichtig ist. Skalierbarkeit ist insbesondere für Webapplikationen und große
Unternehmensanwendungen eine Wichtige Eigenschaft für ein Softwaresystem. Während man bei normalen Desktop-Anwendungen ungefähr absehen
kann welche Leistung erwartet wird, kann dies bei den anderen Systemen
nicht vorhergesagt werden. Für einen Webserver ist es z.B. eine wichtige
Eigenschaft eine gewisse Reaktionszeit zu gewährleisten. Diese Reaktionszeit darf bei einem überdurchschnittlichem Zugriff nicht zu stark einbrechen,
oder gar den Server zum Absturz bringen. Zuverlässigkeit ist ein weiterer
sehr wichtiger Punkt. Benutzer erwarten von einem System, das es immer
zuverlässig arbeitet und allzeit erreichbar ist. Wenn nur eine einzige Komponente ausfällt, im Hardware-, Software- oder auch im Netzwerkbereich ist
evtl. die gesamte Applikation nicht mehr verfügbar. Zuverlässigkeit ist ein
sehr wichtiges Kriterium für Software, da ein großer Teil der Erwartungen
daran geknüpft ist, und sich Kunden von Applikationen darauf verlassen,
das das Softwaresystem einwandfrei arbeitet.
Als letzten großen Vorteil von J2EE möchte ich noch anführen, das es für
die Entwicklung von Softwarekomponenten oder auch ganzen Applikationen bereits eine Fülle von Design-Patterns gibt, auf die man als Entwickler
zurückgreifen kann. Diese Patterns bieten konkrete Entwurfsmuster für die
Entwicklung von bestimmten Softwarekomponenten, die den eigenen Entwurf, aber auch die Implementierung unterstützen. Selbsterstellte Patterns
können z.B. auch Firmenintern weiterverwendet werden, und stellen so ein
wertvolles Nebenprodukt neben dem eigentlichen Entwicklungsprozess dar.
2.2.2 Servlets
Servlet Interface
Servlets sind Webkomponenten die dazu benutzt werden können dynamischen Inhalt für Web-Seiten zu erzeugen. Sie funktionieren über ein Request/Responsemodell. Servlets erhalten z.B. einen HTTP-Request, führen dann
23
Kapitel 2 Grundlagen
ihre Funktion aus und erzeugen einen Response der an den anfragenden WebBrowser geschickt wird. Die Methoden zur Request-Bearbeitung sind entsprechend den HTTP-Anfrage-Typen doGet, doPost, . . . . Servlets müssen
entweder das Java Servlet Interface implementieren, oder von einer Klasse erben die dieses Interface implementiert. Standard Servlet-Klassen sind
GenericServlet und HttpServlet.
Request/Response
Wird das Servlet aufgerufen so werden automatisch vom Container einige
implizite Objekte erzeugt. Die wichtigsten sind die Objekte Request und
Response. Über das Request-Objekt werden alle wichtigen Informationen
wie z.B. Parameter, Informationen über den Servlet-Context, den zum Request gehörenden HTTP-Header, Pfadelemente, Cookie-Informationen, SSLSicherheitsinformationen und noch vieles mehr übergeben. Der Request kapselt die gesamte Servlet-Eingabe in Objekte, die dann ausgelesen werden
können. Auch der Container kann Informationen über das Request-Objekt an
das Servlet weitergeben. Das Response-Objekt kapselt die Servlet-Ausgabe.
So können zum Beispiel die Ausgabe-Objekte zugegriffen, Puffer verwaltet,
Cookies angelegt und HTTP-Header für die Antwort generiert werden. Die
Funktionsweise kann man wie folgt beschreiben: Ein Servlet wird aufgerufen und mittels der HTTP-Übergabefunktionen GET oder POST werden
Parameter an das Servlet weitergegeben. Das Servlet überschreibt nun die
Methoden doGet() und doPost(), um die entsprechenden Anfragetypen zu
bearbeiten. Je nach Anfragetyp wird eine der beiden Funktionen aufgerufen.
Die Funktionen doGet() und doPost() erhalten als Übergabewert die Objekte
request vom Typ HttpServletRequest und response vom Typ HttpServletResponse. Nun können aus dem Request-Objekt die Parameter ausgelesen werden. Die Daten werden dann verarbeitet oder eine beliebige Funktionalität
erfüllt, je nachdem was die Servlet-Aufgabe ist. Dann kann man z.B. über das
Response-Objekt einen PrintWriter erzeugen und danach mit einfachen Ausgabefunktionen wie println() direkt in die Servlet-Ausgabe schreiben und ein
HTML-Dokument erzeugen, das dann an den Absender des Requests zurückgeschickt wird.
Servlet-Lebenszyklus
Servlets haben einen festgelegten Lebenszyklus. Beim der ersten Anfrage
an das Servlet wird es vom Servlet-Container, z.B. einem Tomcat, geladen
und instanziiert. Als nächstes wird das Servlet initialisiert. Dabei wird die
Init-Methode aufgerufen. Dies passiert nur beim ersten Aufruf. Hier wird im
24
2.2 J2EE, Servlets und JSP
Normalfall die Servlet-Umgebung initialisiert. Vorbereitende Tätigkeiten wie
das Öffnen einer Datenbankverbindung können hier erledigt werden. Danach
wird die Service-Methode des Servlets aufgerufen. Für jede Anfrage die nach
der ersten getätigt wird, wird ein Thread gestartet der die entsprechende
Service-Methode (doGet und doPost, wie oben beschrieben) aufruft. So ist
eine parallele Abarbeitung mehrerer Anfragen möglich. Für Servlets bedeutet
das, das alle Globalen Variablen, sowie Zugriffsfunktionen auf Datenbanken
oder Dateien synchronisiert werden müssen. Java bietet hier bereits eine volle Unterstützung. Bei Variablen, Methoden und Funktionen wird einfach das
Schlüsselwort synchronized verwendet. Java implementiert dann einen Zugriffsschutz über ein Semaphorenkonzept. Es gibt alternativ die Möglichkeit
ein Servlet über ein SingleThreadInterface zu implementieren. Dann werden die Anfragen nacheinander abgearbeitet, was allerdings in der Praxis
für eine hochfrequentierte Webseite nicht in Frage kommt. Am Ende wird
das Servlet vom Container über eine destroy-Methode beendet. Hier werden
noch Aufräumarbeiten erledigt wie z.B. das Schließen von Dateien oder das
Schließen einer Datenbankverbindung.
Sessions
Bei dem Zugriff auf Webapplikationen ist es wichtig, das die Anwendung den
Benutzer während seiner Sitzung eindeutig identifizieren kann. Hierzu gibt
es so genannte Sessions. Im allgemeinen werden Sessions durch Cookies oder
durch URL- rewriting realisiert. Bei der Verwendung von Cookies wird ein
kleiner Datensatz mit einer Identifikation auf den Client geladen, die dann bei
jeder weiteren Anfrage verwendet wird. Bei URL-rewriting werden später folgende Anfragen durch hinzufügen von Parametern so verändert, das z.B. eine
Session-ID oder der Name mit übergeben wird. Sessions sind im Servlets über
ein Session-Objekt realisiert, das vom Request-Objekt geholt werden kann.
Das setzen von Cookies erfolgt über das Response-Objekt. Die Session wird
auf dem Server gespeichert und dem zugehörigen Client durch Cookies und
URL-Rewriting zugeordnet. Das Session-Objekt bietet noch mehr. Es stellt
eine Datenstruktur auf Parameter/Wert Basis zur Verfügung in die Daten
gespeichert werden können. So könnte man z.B. eine typische shopping-cart
Anwendung über das Session-Objekt realisieren. Sitzungen werden entweder
automatisch nach einer festgelegten Zeitspanne beendet, oder explizit über
die invalidate-Methode [9] .
25
Kapitel 2 Grundlagen
Filter
Filter sind Java Komponenten, die dazu genutzt werden können, einen HTTPRequest, oder -Response zu manipulieren. Anwendungsgebiete sind etwa
Ver- oder Entschlüsselungen, oder aber das anpassen an einen kompatiblen
Header-Typ. Weitere Anwendungsgebiete sind Kompression, Bildkonvertierungen, aber auch Logfunktionen und XSLT-Konvertierung für die Darstellung von XML-Daten. Filter werden den eingehenden Requests direkt zugeordnet und können diese Request-Methoden überschreiben. Welcher Filter
aufgerufen wird hängt von dem ihm zugeordneten Servlets ab.
2.2.3 JSP
Definition
Java Server Pages sind die J2EE Technologie um Applikationen zu bauen die
dynamischen Web-Inhalt erzeugen. Im Gegensatz zu Servlets eignen sie sich
besser um HTML und die Java-Funktionalität zu kombinieren.
Funktionsweise
JSP-Seiten werden von einem JSP-fähigen Webserver durch eine JSP-Engine
in ein Servlet übersetzt und dann wie die vorher beschriebenen Servlets ausgeführt. Grundsätzlich ist die Technologie eng mit Servlets verwandt, jedoch
werden hier beim erstellen der dynamischen Seite Scriptingelemente, Direktiven und Aktionen in HTML eingebettet, und nicht wie bei Servlet die
HTML-Komponenten in den Javacode. In der Ausführung unterscheiden sie
sich aber kaum.
Lebenszyklus
Beim ersten Aufruf einer JSP Seite, die im *.jsp Format auf dem Webserver vorliegt, wird die JSP-Datei in ein Servlet übersetzt. Dieses Servlet
wird dann kompiliert und wie ein Servlet ausgeführt. Hierbei werden die
im Servlet-Abschnitt bereits erwähnten Stadien wie Init(), Service(), und
destroy() durchlaufen. Auch JSP laufen wie Servlets bei mehreren Anfragen
in verschiedenen Threads ab, die jeweils nur die Service-Methode ausführen.
Die nötigen Synchronisationsmechanismen müssen vom Programmierer der
Seite verwendet werden. Aus Performanzgründen kompilieren einige Server
26
2.2 J2EE, Servlets und JSP
die JSP schon vor dem ersten Aufruf, um die erste Anfrage genauso schnell
bearbeiten zu können wie die übrigen.
Aufbau einer JSP-Seite
Ein JSP-Seite besteht im wesentlichen aus HTML-Code, Scriptingelementen, Direktiven, und Aktionen. Im folgenden werden Scriptingelemente, die
wichtigsten Direktiven sowie die wichtigsten Aktionen, die Standardaktionen, und TagLibs kurz erläutert.
Scriptingelemente Mit Scriptingelementen kann man Code in das Servlet
einfügen, das von der JSP-Seite generiert wird. Es wird zwischen drei Formen
unterschieden [9] :
• Ausdrücke haben die Form <%= expression%>. Ausdrücke werden ausgewertet und direkt in die Seite eingefügt, also später direkt als HTML
ausgegeben.
• Scriptlets haben die Form <% code %>. Mit Hilfe von Scriptlets kann
vollständiger Javacode in die HTML-Seite eingebettet werden. Komplexe Berechnungen oder aber auch Kontrollstrukturen für die HTMLAusgabe können so realisiert werden. Der Javacode in den Scriptlets
steht später im Servlet in der Service-Methode.
• Deklarationen haben die Form <%! code %>. In Deklarationen kann
ebenso wie ein Scriptlets Javacode eingebettet werden. Im Gegensatz
zu Scriptlets wird dieser Code jedoch später außerhalb der ServiceMethode abgelegt. Hier können zum Beispiel Methoden oder Globale
Variablen definiert werden.
Kommentare haben die Form <%– – Kommentar – –%>
Direktiven Direktiven dienen dazu die Gesamtstruktur des Servlets zu kontrollieren und dazu mit dem Container zu kommunizieren. Sie werden beim
Übersetzen der JSP-Seite ausgeführt. Direktiven haben die Form:
<%@ Direktive {Attribut = ,, Wert ”} %>. Die wichtigsten Direktiven sind
die page-, include- und die taglib-Direktive, die im folgenden genauer beschrieben werden.
27
Kapitel 2 Grundlagen
• Die page-Direktive dient dazu einer JSP Seitenattribute zuzuweisen.
Solche Attribute sind zum Beispiel das setzen einer zugehörigen Fehlerseite bzw. das definieren der aktuellen Seite als Fehlerseite. Das import Attribut ist mit dem einbinden von Javaklassen oder -Packages
zu vergleichen. Es kann weiterhin definiert werden ob die JSP-Seite in
einer Session enthalten sein muss, oder es können Puffer-Attribute und
Informationen über die Zeichencodierung gesetzt werden. Der Syntax
der page-Direktive ist:
<%@ page {Attributliste} %> . Die Attributliste besteht dann aus einer
Liste mit Attributen und den zugewiesenen Werten. Hier alle Attribute:
extends, import, session, buffer, isThreadSafe, isErrorPage, errorPage,
contentType, pageEncoding, language, autoFlush, info, isELIgnored.
• Die include-Direktive dient dem ineinander Einfügen von Code, vergleichbar einer Substitution. So kann z.B. zur Kompilationszeit eine
andere JSP-Seite, aber auch statischer Inhalt direkt in die aktuelle JSPSeite eingebunden werden. Dies erspart Mühe wenn spezielle, häufig
gebrauchte Teile von JSP oft geändert oder erneuert werden müssen.
Der Syntax der include-Direktive ist:
<%@ include page/file=,,URI”Attributliste%>, wobei page einen statischen und dynamischen Inhalt,und file nur einen statischen Inhalt
einfügen kann.
• Die taglib-Direktive hat die Funktion Tag-Bibliotheken einzubinden,
die später noch erläutert werden. Syntax hier:
<%@ taglib uri=,,tagliburi” prefix=,,tagprefix” %> , wobei tagliburi
eine absolute oder relative Adresse der Tag-Bibliothek, und tagprefix
das hier im Dokument zu verwendende Tag ist. Verwendung und Anwendungsgebiete werden später noch beschrieben.
Implizite Objekte Wenn eine JSP-Seite aufgerufen wird und der vorliegende Request bearbeitet wird, werden einige Objekte implizit erzeugt, auf
die dann sofort zugegriffen werden kann. Die wichtigsten impliziten Objekte
sind:
• request, das bereits vom Servlet bekannte javax.servlet.http.HttpServletRequest Objekt, das diverse Parameter und Funktionen zur Anfrage
des Clients bietet. Es kann genau wie im Servlet verwendet werden.
• response, ebenfalls vom Servlet bekannt bietet es Parameter und Funktionen um die Antwort an den Client zu definieren.
Typ: javax.servlet.http.HttpServletResponse
28
2.2 J2EE, Servlets und JSP
• out, vom Typ javax.servlet.jsp.JspWriter, ist von java.io.Writer abgeleitet. Dient der JSP-Ausgabe.
• session, vom Typ javax.servlet.http.HttpSession, ist ebenfalls vom Servlet bekannt. Dient zur Verwaltung von Sitzungen und kann zum Speichern Sitzungsbezogener Daten genutzt werden.
• application, vom Typ javax.servlet.ServletContext, stellt der JSP-Seite
eine Sicht auf seine Umgebung zur Verfügung.
• config, vom Typ javax.servlet.ServletConfig. Kann genutzt werden um
die Konfiguration auszulesen.
• pageContext, vom Typ javax.servlet.jsp.PageContext, bietet weitere
Funktionalitäten für den JSP-Einsatz in JSP-Umgebung [?]
• page, vom Typ java.lang.Object.
Mit Hilfe dieser impliziten Objekte ist bereits ein umfangreiche Grundlage
geboten um komfortabel JSP programmieren.
Standardaktionen Standardaktionen bieten, zusätzlich zu den impliziten
Objekten, eine weitere zusätzliche Funktionalität von Java Server Pages. Sie
werden in XML-Syntax geschrieben und haben das Prefix jsp. Im Folgenden
werden die wichtigsten erläutert:
• <jsp:usebean> Wird verwendet um JavaBeans in JSP zu benutzen.
Die beans werden hiermit erzeugt und bekommen einen Namen(ID) zugewiesen. Syntax: <jsp:usebean id=,,name’’class=,,classname’’>.
Mit Hilfe der Standardaktionen jsp:setProperty und jsp:getProperty
können ihnen Werte zugewiesen oder Werte ausgelesen werden. Alternativ können auch die in den Beans realisierten Lese- und Schreibmethoden verwendet werden.
• <jsp:include>, kann andere JSP direkt in die aktuelle einbetten. Syntax:
<jsp:include page="JspFilePfadName\ flush=true/>.
Dies kann dazu verwendet werden vordefinierte Teile von Seiten häufiger zu verwenden oder um die JSP-Dateien übersichtlicher zu machen.
• <jsp:forward>. Diese Aktion gibt die Verarbeitungreihenfolge an die
spezifizierte Seite weiter. Der Rest der aktuellen wird nicht weiter
durchlaufen. Syntax: <jsp:forward page="JspFilePfadName\ />
29
Kapitel 2 Grundlagen
• <jsp:plugin> Mit dieser Aktion können Plugins, wie z.B. Applets
eingebunden werden. Parameterübergabe erfolgt über die Aktionen
jsp:param bzw. jsp:params. Eine Alternative falls das plugin nicht geladen werden kann bietet jsp:fallback. Diese Aktionen können innerhalb
des jsp:plugin Tags benutzt werden.
Beispiel:
<jsp:plugin type="applet" code="Molecule.class"
codebase="/html" >
<jsp:params>
<jsp:param name="molecule"value=
"molecules/benzene.mol"/>
</jsp:params>
<jsp:fallback> <p>
unable to start plugin </p>
</jsp:fallback>
</jsp:plugin>
Diese Standardaktionen können mit den im folgenden Abschnitt beschriebenen TagLibs erweitert werden.
TagLibs Mit Hilfe von Tag-Bibliotheken ist es möglich weitere Aktionen
als die Standardaktionen zu definieren und diese dann in JSP zu benutzen.
Somit können auch komplexe Strukturen und Funktionalitäten auf der JSP
in einfacher XML-Schreibweise genutzt werden, was insbesondere auch für
nicht-Programmierer, z.B. die Webdesigner einen Vorteil bietet. JSP wurde geschaffen um das Zusammenspiel von Webdesignern und Programmierern zu erleichtern, wobei die TagLibs eine zentrale Rolle spielen. Der Designer hat keine komplizierte Code-Fragmente auf seiner Seite sondern einfach XML-Tags, die für ihn, bei guter Dokumentation, einfach zu handhaben
sind. TagLibs beinhalten üblicherweise mehere Funktionen die dann über ein
Tag mit nachgestelltem Funktionsnamen verfügbar sind. Um die einzelnen
Tag-Funktionen zu schreiben muss man eine Tag Handler-Klasse schreiben,
die das Interface Tag implementiert. Tag Handler-Klassen sind JavaBeans.
Die Parameter werden per Name im Tag übergeben. Wenn der Server das
entsprechende Tag findet erzeugt er eine Instanz der zugehörigen Klasse und
übergibt die Werte über die entsprechenden set und get Methoden. In der Tag
Handler-Klasse müssen folgende Methoden enthalten sein, die beim öffnen
bzw. beim schließen des Tags aufgerufen werden: doStartTag() und doEndTag().
30
2.2 J2EE, Servlets und JSP
Anwendungsgebiete von Servlets und JSP
Anwendungsgebiete von Servlets und JSP sind insbesondere Webapplikationen. Jedoch lassen sich insbesondere mit JSP auch kleine dynamische Seiten
erstellen, die man sonst evtl. mit PHP oder dem weniger mächtigen Javascript erstellt hätte. JSP bieten sich durch ihre Eigenschaften und ihren
speziellen Funktionsumfang als Präsentationsschicht für Webapplikationen
an. Ein Professioneller Webdesigner kann eine Seite erstellen und dabei evtl.
auf mächtige TagLibs zurückgreifen. Die Designfrage spielt in der heutigen
Zeit bei einem riesigen Angebot an Webseiten eine immer wichtigere Rolle,
weshalb der Einsatz von Profis in diesem Bereich oft sinnvoll erscheint. JSP
bietet genau hier eine gute Unterstützung. Die Trennung von Design und
Hintergrundlogik ist hier ideal realisiert. Mit Hilfe der Servlets und dem riesigen J2EE Paket dahinter kann man mächtige Applikationen erstellen und
im Web zur Verfügung stellen. Die J2EE bieten eine große Bibliothek die
Datenbankzugriffe und andere wichtige Funktionen einer großen Anwendung
direkt zugreifbar machen.
31
Kapitel 2 Grundlagen
Abbildung 2.8: J2EE Architektur Diagramm
32
2.3 Webapplikationen mit J2EE
2.3 Webapplikationen mit J2EE von Heike Kraef
2.3.1 Einleitung
Je vielfältiger die Anwendungen im Internet werden, desto wichtiger wird
die Möglichkeit, auf die Benutzer angepasste Internetpräsenzen anbieten zu
können. Auch soll auf das Nutzerverhalten dynamisch eingegangen werden
können. Die Schwierigkeit, die zu lösen ist, ist dabei, dabei das die Services
Übersichtlich und geordnet bleiben um sie auch warten und verbessern zu
können.
Um all das zu vereinfachen und eine strukturiertes Modell zu haben, wurde
von Sun J2EE eingeführt. J2EE definiert einen Standard für die Entwicklung
von komponentenbasierten mehrschichtigen Internet-Applikationen. Ausserdem enthält es verschiedene Entwicklungswerkzeuge. Dies alles ist auf der
Internetpräsenz von Sun als auf diesen Bereich abgestimmte Klassenbiblithek(SDK) zusammen mit anderen Tools erhältlich.
Diese Arbeit behandelt die verschiedene Begriffe, die in diesem Zusammenhang immer wieder auftauchen und auch zum Teil die praktische Anwendung
dieser J2EE-Spezifikation innerhalb des Tomcat-Servers von Apache.
2.3.2 J2EE
Der Aufbau von J2EE ist, wie man in der Abbildung 2.9 sieht, sehr einfach
gehalten. Auf der linken Seite liegt der komplette Teil, welcher auf der Seite
Abbildung 2.9: Übersicht über den J2EE-Aufbau
des Nutzers vorkommen kann. Dabei kann der Nutzer entweder über einen
herkömmlichen Internet-Browser auf die Informationen, bzw. Internetseiten
33
Kapitel 2 Grundlagen
oder andere Services, zugreifen, oder über einen sogenannten ApplicationClient, also ein auf die Aufgabe speziell abgestimmtes Programm. Bei dieser Art von Client hat man, im Gegensatz zu einem normalen Browser, die
Möglichkeit nicht nur mit dem Web-Container-Teil des Servers zu komunizieren, sondern eine eigene Oberfläche, z.B. mit den Java-Swing-Klassen, zu
entwickeln und dann direkt mit den Komponenten des EJB Containers zu
komunizieren. Bei einem Browser ist dieser direkte Weg ausgeschlossen. Ein
Browser kann nur indirekt, über den Web-Container, mit dem EJB-Container
kommunizieren.
Der EJB-Container, bzw. seine Komponenten sollen hier nicht weiter betrachtet werden; der Webcontainer jedoch wird im folgenden noch genauer
beschrieben.
Web-Container
Der Web-Container kann abstrakt als eine Art Gruppierung betrachtet werden, welche die Webapplikationen und die zur Ausführung notwendigen Komponenten enthält. Dementsprechend kann man den Webcontainer auch als
eine Art Schnittstelle bezeichnen, welche über eine definierte, immer gleiche, Struktur die Informationen ihrer Komponenten nach Außen weiter gibt.
Es gibt unter anderem einen Ansatz von Apache (Geronimo) bei dem diese Schnittstelle als java-Interface-Klasse implementiert wurde, so dass eine
Klasse, die diese implementiert, auf jeden Fall die folgenden Methoden enthalten muss:
void deploy(String url): Führt eine Webapplikation aus.
String getDefaultWebXmlURL(): Gibt die URL der Beschreibungs-Datei2
zurück die von diesem Container genutzt wird.
void setDefaultWebXmlURL(String url): Setzt den Pfad auf BeschreibungsDatei die dieser Container nutzt.
Dadurch wird sicher gestellt das jede Webapplikation auf die gleiche Weise
angesprochen und genutzt werden kann.
Webapplikation
Webapplikationen sind, im Gegensatz zu den gleich bleibenden Teilen eines
Webservers, die dynamische Erweiterung eines Web oder Application Server.
2
34
siehe Kapitel 2.3.3
2.3 Webapplikationen mit J2EE
Dabei sind die statischen Teile, z.B. die zur generellen Komunikation benötigten verschiedenen, unterstützten Protokolle (ftp, html, ssh, ...), unabhängig
von den angebotenen Services. Grundlegend gibt es zwei unterschiedliche
Variationen von Webapplikationen. Zum einen service-orientierte Webapplikationen, die reine Daten ohne optische Repräsentation liefern. Zum anderen
präsentations-orientierte Webapplikationen, die im Gegensatz zu den serviceorientierten, eine optische Repräsentation beinhalten. Das bedeutet in der
Praxis, dass eine präsentations-orientierte Webapplikation z.B.eine htmlDatei oder eine XML-Datei liefert, wobei diese XML-Datei nur präsentationsorientiert ist falls ein Stylesheet mit geliefert wird.
Bei der Java2 Plattform stellen die Web Komponenten, wie z.B. JSP, Servlets
(siehe auch [15]) und Webservice Endpunkte3 , diese dynamische Erweiterbarkeit bereit.
Praktische Anwendung
Um nun eine Webapplikation, deren Teile unter anderem JSPs und Servlets
sind, z.B. in einer Internet-Präsenz nutzen zu können, stellt sich die Frage
wie man sie starten und nutzen kann. Dazu braucht man erst einmal ein Java
Development Kit (JDK), um die genannten JSPs und Servlet überhaupt erst
einmal zu erzeugen und eventuell noch einige Klassen schreiben zu können,
welche die für die JSPs und Servlets benötigten Daten liefern.
Doch um nun die geschriebene Webapplikation im Internet bereitstellen zu
können, benötigt man noch einen Server der es möglich macht, auf die Applikation von Aussen zuzugreifen, z.B. Tomcat, auf den im folgenden noch
näher eingegangen wird.
Des weiteren benötigt man ein Building Tool mit dem man Anweisungen
bzgl. des Servers in ausführbare Dateien schreiben kann. Diese Dateien sollten möglichst so aufgebaut werden können, dass es auf die Anfordernisse eine
Webservers angepasst ist. Es bietet sich hier an das Tool ”Ant” zu nutzen,
da dieses auf XML-Basis4 funktioniert und bereits Tags anbietet mit deren
Hilfe die Konfigurationen des Servers einfacher werden.
Zu guter Letzt ist es ratsam, ein Concurrent Versions System (CVS) zu nutzen, mit Hilfe dessen man Veränderungen die man an den Webapplikationen
vorgenommen hat wieder Rückgängig machen kann, falls sich mal ein Fehler
eingeschlichen haben sollte.
3
4
Punkt, an dem der Teil den der Nutzer noch sieht, aufhört
siehe Kapitel 2.3.4
35
Kapitel 2 Grundlagen
2.3.3 Der Tomcat-Server
Der Tomcat-Server ist ein Application-Server von Apache der die Spezifikationen von J2EE, bzw. das entsprechende Schichtenmodell einhält. Der
Abbildung 2.10: Übersicht über den Aufbau des Tomcat-Servers
Server besteht, wie man in Abbildung 2.10 sieht, aus folgenden Komponenten:
Connector: Diese Teile, von denen es mehrere geben kann, sind die Übersetzer von verschiedenen HTTP-Protokollen (HTTP/1.0, HTTP/1.1,
HTTPD, ...) in ein allgemeines Format, das der eigentliche Server verstehen kann.
Service: bildet die Schnittstelle zwischen mehreren Connectors und genau
einer Engine.
Engine: fasst mehrere Hosts zu einer gesammelten Schnittstelle zusammen
(verteilte Systeme).
Host: entspricht einem Rechner, der durch eine URL identifiziert werden
kann.
Context: entspricht mehreren Webapplikationen auf einem Host.
Tomcat-Ordner-Struktur
Der Tomcat-Server ist aus der Perspektive des Nutzers nichts anderes als eine
Struktur von einigen Ordnern, die teilweise wieder ausführbare Programme
36
2.3 Webapplikationen mit J2EE
und Skripte enthalten um den Server aktivieren, deaktivieren und warten zu
können.
So liegen z.B. im Home-Verzeichnis des Servers folgende Verzeichnisse:
bin/ : Startup- , Shutdown- und andere Skripte.
conf/ : Konfigurationsdateien und DTDs5
webapps/ : die verschiedenen Webapplikationen in Unterordnern oder als
WAR-Datei
logs/ : Log-Dateien des Servers, also Text-Dateien mit den anfragen, ...
common/lib : JAR Dateien, welche von allen Webapplikationen und internen Tomcat Funktionen genutzt werden.
shared/lib : von allen Webapplikationen genutzte JAR -Dateien
Die einzelnen Webapplikationen haben zusätzlich auch noch eine Verzeichnisstruktur. Oft wird für jede Webapplikation, wie oben beschrieben, ein eigener Ordner im Verzeichnis webapps/ erzeugt. Innerhalb von diesem neuen
Ordner wird nun noch folgende Ordner-Struktur angelegt:
aktuelles Verzeichnis: hier werden die *.html und *.jsp Dateien abgelegt.
/WEB-INF/ : In dieses Verzeichnis wird die Datei web.xml, also der Web
Application Deployment Descriptor6 gespeichert.
/WEB-INF/classes/ : alle in dieser Webapplikation benötigten Java-class
Dateien (servlets und andere)
/WEB-INF/lib/ : alle in dieser Webapplikation benötigten *.jar-Dateien
Statt dieser Verzeichnisstruktur kann man diese Hierarchie auch in einem
”Web application archive” speichern. So eine *.war Datei ist eine *.jar Datei,
also eine gepackte Version der Ordner, mit anderer Endung um deutlich zu
machen was darin enthalten ist. Jedoch werden solche Dateien zur Laufzeit
entpackt um auf die Inhalte zugreifen zu können.
5
6
siehe Kapitel 2.3.4
XML-Datei die beschreibt welche Services diese Webapplikation bereit stellt
37
Kapitel 2 Grundlagen
2.3.4 Web Services
Ein Web Service ist ein Dienst, der mit Hilfe von XML auf der Basis von
Internet-Netzwerkprotokollen zur Verfügung gestellt wird. Web Services bilden die drei wichtigsten Teile der Zusammenarbeit ab: Das Zusammenfinden,
Binden und den Datenaustausch [23,16]. Diese Begriffe sind wie folgt zu verstehen:
Datenaustausch: Der Datenaustausch wird hauptsächlich mit der Hilfe von
SOAP und HTTP durchgeführt. Alternativ zu SOAP kann der Datenaustausch auch über XML-RPC erfolgen. Auf XML-RPC wird im
folgenden nicht näher eingegangen.
Zusammenfinden: Einen Web Service kann automatisch via UDDI7 gefunden werden. UDDI selbst basiert auf SOAP über HTTP. Weitere Protokolle sind angedacht und teilweise standardisiert, wie zum Beispiel
WSIL.
Binden: Das Binden zwischen dem Verzeichnis(UDDI) und dem Server,
auf dem der Web Service bereit gestellt wird, dominiert der WSDL
Standard. In WSDL kann man alle wichtigen Informationen ablegen,
die man benötigt, um auf einen Web Service zuzugreifen. Ein Vorgänger
von WSDL ist DISCO.
XML
Extensible Markup Language (XML) ist ein textbasierter Standard zur Datendarstellung. Das bedeutet, das man mit Hilfe dieses Standards Daten
strukturiert und übersichtlich verwalten kann. Dazu kann man in einem Schema (in DTDs8 ) eigene Tags definieren.
Tags sind Schlüsselwörter die die Daten gliedern. So könnte man beispielsweise, wenn man die Daten von mehrere Personen im XML-Format speichern
wollte, Tags für Name, Vorname, Adresse usw. definieren. Ein Tag wird dabei mit spitzen Klammern kenntlich gemacht, wobei das Tag am Ende eines
Datenfeldes mit einem Slash hinter der öffnenden Klammer geschrieben wird.
Ein XML-Datensatz zum vorigen Beispiel sähe dann z.B. wie folgt aus:
XSLT option disabled!
<?xml version="1.0" ?>
<adressliste>
7
8
Verzeichnisdienst der Unternehmen, der ihre Daten und ihre Services enthält.
Document Type Definitions
38
2.3 Webapplikationen mit J2EE
<kunde>
<nachname>Gans</nachname>
<vorname>Gustav</vorname>
<adresse>Entenhausenerstr. 12</adresse>
<ort>Federbach</ort>
</kunde>
</adressliste>
Der Vorteil einer solchen Datenhaltung ist es, das die Daten, im Gegensatz zu
html-Dateien, getrennt von ihrer Darstellung gespeichert werden. Um diese
Daten darstellen zu können werden Stylesheets definiert, die ihrereseits wiederum definieren wie die einzelnen Tags angezeigt werden sollen. Das wiederum hat den Vorteil, dass es so wesentlich leichter wird, die Darstellung der
Daten z.B. an einzelne Nutzer anzupassen. So ist es beispielsweise möglich,
dass, wenn mehrere Firmen die gleichen Daten auf einem zentralen Server
nutzen, diese Daten innerhalb einer eigenen Firmenseite mit angepasstem
Logo usw. erscheint.
WSDL
Die Web Services Description Language (WSDL) ist ein plattform-, programmiersprachen- und protokollunabhäniges XML-Format zur Beschreibung von
Web-Services. Eine solche Beschreibung enthält, wie man im folgenden Beispiel des Übersetzungsservices Babelfish sieht, unter anderem den Namen,
den Ort und die Kommunikationsarten des Services:
<definitions name="BabelFishService"
targetNamespace=
"http://www.xmethods.net/sd/BabelFishService.wsdl">
<message name="BabelFishRequest">
<part name="translationmode" type="xsd:string"/>
<part name="sourcedata" type="xsd:string"/>
</message>
<message name="BabelFishResponse">
<part name="return" type="xsd:string"/>
</message>
<portType name="BabelFishPortType">
<operation name="BabelFish">
<input message="tns:BabelFishRequest"/>
<output message="tns:BabelFishResponse"/>
</operation>
39
Kapitel 2 Grundlagen
</portType>
<binding name="BabelFishBinding"
type="tns:BabelFishPortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="BabelFish">
<soap:operation soapAction="urn:xmethodsBabelFish#BabelFish"/>
<input>
<soap:body use="encoded"
namespace="urn:xmethodsBabelFish"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:xmethodsBabelFish"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="BabelFishService">
<documentation>
Translates text of up to 5k in length, between a variety
of languages.
</documentation>
<port name="BabelFishPort"
binding="tns:BabelFishBinding">
<soap:address location=
"http://services.xmethods.net:80/perl/soaplite.cgi"/>
</port>
</service>
</definitions>
In disem Beispiel ist ersichtlich, das die Beschreibung dieses Services in verschiedene Teile gekapselt ist. Die äußerste Kapsel ist das Tag definitions.
Sie beinhaltet unter anderem den Namen des Web Services. In der nächsten
Ebene gibt es die Tags types,message, porttype, binding und service [22]. Das
Tag types kommt in dem Beispiel nicht vor. In ihm kann man eigene Typen
definieren. Da in dem Beispiel aber nur ein einfache Typen enthält(string)
ist dies hier nicht nötig. message definiert die Art der auszutauschenden Daten. Hier entsprechen die beiden Messages dem eingegebenen Wort und dem
übersetzten Ergebnis. Diese Definition wird nun wiederum im porttype um
40
2.3 Webapplikationen mit J2EE
die Übermittlungsart einer, hier BabelFish genannten, Operation fest zu legen. In diesem Beispiel wird dies so definiert, dass der Endpunkt auf eine
Anfrage eine Antwort sendet(Request-response).
Weitere Alternativen, auf die ich hier aber nicht eingehen werde, wären Oneway, Solicit-response oder Notification. Das daraufhin folgende Tag ist binding. Hier wird nun das konkrete Protokoll und das Datenformat für einen
PortType festgelegt. In dem Beispiel wird für unsere zuvor definierte Operation das SOAP-Protokoll zur Übertragung der Messages festgelegt, und auch
wo die Definition des Protokolls bzw. die Definition der hier zu nutzenden
Encoding Styles zu finden ist. Zu guter Letzt bleibt noch das Tag service.
Dieses Tag beinhaltet unter anderem die Dokumentation, was der Service
tut, und teilt innerhalb von hier definierten Ports den einzelnen Bindings
genaue Adressen zu.
Diese Beschreibung kann in der UDDI Registry gespeichert und so im Web
veröffentlicht werden, so dass auch andere Firmen oder auch Privatleute auf
diese Services zugreifen können.
SOAP
Das Simple Object Access Protokoll, kurz SOAP, ist ein XML-basiertes Kommunikationsprotokoll, dass unabhängig vom Transportprotokoll definiert ist
und daher nicht nur über HTTP sondern auch über FTP oder andere Protokolle arbeiten kann. Die wichtigsten Prinzipien sollen dabei ”simplicity and
extensibility” also Einfachheit und Eweiterbarkeit sein. Diese Prinzipien sind
durch XML leicht zu erfüllen. Um nun Daten verschicken zu können, müssen
diese in eine ”SOAP-Message” verpackt werden, die wie in Abbildung 2.11
ersichtlich aus folgenden Teilen besteht:
SOAP Envelope: kappselt Header und Body und enthält z.B. Anweisungen
wie die Nachricht dekodiert werden muss.
SOAP Header: übernehmen Aufgaben wie Authentifizierung, Transaktionsmanagement usw.; es kann mehrere innerhalb einer Nachricht geben.
SOAP Body: die eigentlichen Daten, die in dieser Message verschickt werden
In der Realität könnte nun eine solche SOAP-Message wie folgt aussehen:
41
Kapitel 2 Grundlagen
Abbildung 2.11: Struktur einer SOAP-Message ohne Attachment
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
</n:alertcontrol>
</env:Header>
<env:Body>
<m:alert xmlns:m="http://example.org/alert">
<m:msg>Pick up Mary at school at 2pm</m:msg>
</m:alert>
</env:Body>
</env:Envelope>
Hier kann man gut sehen, dass die einzelnen Teile der SOAP-Message durch
XML-Tags gegliedert sind, und das auch die Inhalte die hier verschickt werden im XML-Format vorliegen.
Inzwischen gibt es sogar Internet-Browser, z.B. Mozilla 1.0, die dieses Protokoll unterstützen, und es über Javascript-Aufrufe möglich machen auch
direkt auf Webservices zugreifen können [13].
Kommunikation
Die Kommunikation von Nutzerapplikationen mit dem Server, wie sie im
Modell von J2EE vorgesehen ist, sieht man in Abbildung 2.12. Dort sieht
42
2.3 Webapplikationen mit J2EE
Abbildung 2.12: Request-Handling in J2EE
man, dass beim Stellen einer Anfrage, z.B. über eine Internetseite, diese
Anfrage als HTTPServlet gestellt wird und dieses wiederum auf Webkomponenten, also auf JSPs, Servlets und html-Seiten, zugreift. Die einzelnen
Webkomponenten greifen dann ihrerseits auf Daten, Prozeduren oder andere
Webapplikationen zu.
In der Praxis ist dieser Verlauf etwas detailierter zu betrachten. Im folgenden Beispiel (siehe auch Abb. 2.13) eine Anfrage an eine Webapplikation
betrachten, welche wiederum auf einen Webservice zurückgreift. In diesem
Beispiel stellt der Nutzer eine Anfrage. Dies geschieht z.B. dadurch das er
sich eine Internetseite anschaut oder auch indem er Beispielsweise ein Formular ausfüllt, abschickt und auf eine Antwort oder ein Ergebnis wartet. Es
gibt unzählige Möglichkeiten wie solch eine Anfrage aussehen kann. Nach
dem die Anfrage mit Hilfe des http-Protokolls versendet wurde, übersetzt
ein Connector diese http-Message in ein dem Kern des Servers bekanntes
http. Dann kann der Server eine Session starten und leitet die Anfrage über
die Engine an die entsprechende Webapplikation weiter. Diese bearbeitet die
Anfrage und liefert nun ihrerseit eine JSP oder eine html-Seite zurück.
Falls die Webapplikation jedoch noch Daten benötigt, die sie selbst an einen
anderen Webservice stellen muss, kann sie, falls dieser ein entsprechendes
Servlet beinhaltet, die Anfrage an des Webservice als SOAP-Nachricht schicken. Diese wird dann bei dem Server, auf dem der Webservice liegt, wieder
43
Kapitel 2 Grundlagen
Abbildung 2.13: Beispiel für den Ablauf einer Anfrage an den Tomcat-Server
mit einem Servlet dekodiert und bearbeitet. Nun muss der Webservice das
Ergebnis wiederum als SOAP-Nachricht kodieren und sie zurück senden.
44
2.4 Das Framework Struts
2.4 Das Framework Struts von Niels Henze
2.4.1 Einleitung
Bei Struts [10] handelt es sich um ein Framework, mit dessen Hilfe sich
das Model-View-Controller (MVC) Konzept für Web-Anwendungen mit Java
umsetzen lässt. Es ist ein Open-Source Projekt, wurde im Jahr 2000 von
Craig R. McClanahan initiiert und fußt auf den folgenden Technologien:
• Java-Server-Pages
• Java-Servlets
• Enterprise-Java-Beans
Im Folgenden wird das MVC Konzept kurz erläutert und die Benutzung
von Struts anhand dieses Konzeptes erklärt. Struts lässt sich von der Seite
http://jakarta.apache.org/struts herunterladen.
2.4.2 Model-View-Controller
Das Model-View-Controller Konzept geht auf Prof. Trygve Reenskaug zurück
und wurde erstmals mit der Sprache Smalltalk implementiert (siehe [17] und
[18]). Das Konzept zerlegt die Benutzungsoberfläche in drei Komponenten:
• Das Model beschreibt die Schnittstellen zur Logik durch Definition von
Datenstrukturen und Methoden
• Die View nimmt Zugriff auf im Model spezifizierte Daten und stellt sie
dar
• Der Controller fungiert als Schnittstelle zwischen View, Model und dem
Benutzer.
Mehrere View- und Controller-Komponenten können dasselbe Model oder
Teile davon darstellen bzw. bearbeiten. Durch die Spezifikation der Schnittstelle zur Logik mit der Komponente Model ist es möglich, die Logik relativ
unabhängig von View und Controller zu entwickeln. View und Controller
sind so relativ einfach auszutauschen, da sie nur mit dem Model verbunden
sind.
45
Kapitel 2 Grundlagen
Abbildung 2.14: Model-View-Controller in Struts
Die Erläuterung wie das MVC-Konzept mit Struts umgesetzt wird, wird mit
einem Beispiel für einen einfachen Registrierungsvorgang erläutert ( [12]). Die
”Startseite”, durch die die Registrierung aufgerufen wird, ist http://.../actions/signup.jsp. Innerhalb der Seite wird dem Benutzer ein Formular präsentiert,
in dem er einige Angaben machen muss. Wenn der Benutzer das Formular
vollständig ausgefüllt hat, wird ihm eine Bestätigungsseite angezeigt. Wenn
Angaben fehlen, wird er aufgefordert, die fehlenden Informationen nachzutragen.
2.4.3 Der Controller
Der Controller hat die Aufgabe, HTTP-Requests vom Client entgegenzunehmen. Zudem muss er entscheiden, welche Funktionen des Models auszuführen
sind und dann die Verantwortlichkeit für das Erzeugen der nächsten Sicht der
Benutzungsschnittstelle an eine passende View-Komponente zu delegieren.
Der Controller wird durch die Komponenten ActionServlet und Configuration gebildet. Die Komponente ActionServlet ist ein Servlet vom Typ ActionServlet. Die Configuration ist eine XML-Datei (struts-config.xml), die
das Verhalten des Servlets beschreibt, indem Aktionen definiert werden. Jede Aktion legt für einen eingehenden HTTP-Request fest, welche ActionKlasse (also eine Klasse, die die Action-Klasse erweitert) verantwortlich ist,
die gewünschte Aktion des Model auszuführen. Nachdem die Action-Klasse
ihre Arbeit erledigt hat, gibt sie einen Wert zurück. Für jeden dieser zurückgegebenen Werte wird festgelegt, welche JSP der View die Antwort für den
46
2.4 Das Framework Struts
Client erzeugt.
Beim Start der Web-Anwendung wird die Konfigurationsdatei vom Servlet
gelesen und das Servlet verhält sich entsprechend.
Struts erlaubt es, logische Namen für die Aktionen zu verwenden, an die die
Kontrolle weitergeleitet werden soll. Eine Aktion-Methode kann somit nach
einer Seite fragen, ohne den tatsächlichen Namen der JSP zu wissen.
Im Folgenden wird die Konfigurationsdatei struts-config.xml des Registrierungsvorgangs erläutert.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
"http://struts.apache.org/dtds/struts-config_1_2.dtd">
<struts-config>
<form-beans>
<form-bean name="contactFormBean"
type="servlets.ContactFormBean"/>
</form-beans>
<action-mappings>
<action path="/actions/signup"
type="servlets.SignupAction"
name="contactFormBean"
scope="session"
input="/forms/signup.jsp">
<forward name="missing-value"
path="/forms/signup.jsp"/>
<forward name=" success"
path="/WEB-INF/results/
confirmation.jsp"/>
</action>
</action-mappings>
</struts-config>
Innerhalb des <form-beans> Tags können FormBeans deklariert werden. Ein
FormBean ist ein Bean, das von Struts automatisch mit dem Inhalt eines Formulars gefüllt wird und von der Klasse ActionForm erbt. Durch das <formbean> Tag wird ein FromBean für die spätere Benutzung in den <action>
Tags deklariert. Die Attribute und Methoden des FormBean müssen mit
47
Kapitel 2 Grundlagen
den Feldern des Formulars, mit dem das FormBean benutzt wird, überein
stimmen. In diesem Fall wird durch die Attribute Folgendes festgelegt:
name:
type:
Der Name mit dem das FormBean in den <action> Tags
angesprochen wird. In diesem Fall also ”contactFormBean”definiert durch name=”contactFormBean”
Der Name der Klasse des FormBean. In diesem Fall
type=”servlets.ContactFormBean”also die Klasse ”servlets.ContactFormBean”
Innerhalb des <action-mappings> Tags werden Aktionen definiert, die bei
einem bestimmten Requests ausgeführt werden. Durch das <action> Tag
wird eine Aktion definiert. In diesem Fall wird durch die Attribute Folgendes
festgelegt:
path:
type:
name:
scope:
input:
Beschreibt
für
welchen
Request
die
Aktion verantwortlich ist. In diesem Fall durch
path=”/actions/signup”ein Request für die Seite
http://domain/anwendung/actions/signup.do,
wobei
das ”.do”implizit angehängt wird.
Beschreibt durch Instanzen welcher Klasse der Request bearbeitet werden soll. In diesem Fall type=”servlets.SignupAction”also eine Instanz der Klasse
servlets.SignupAction.
Der Name eines in den <form-beans> Tags deklarierten
Bean. In diesem Fall durch name=”contactFormBean”das
oben deklarierte Bean.
Die Gültigkeitsdauer des Beans. In diesem Fall durch scope=”session”hat das Been die Gültigkeitsdauer einer Session.
Die Adresse der JSP, welche eine Input-Form enthält.
In diesem Fall input=”/forms/signup.jsp”also die JSP signup.jsp.
Durch die <forward> Tags wird festgelegt, welche JSP aufgerufen werden
sollen. Das Action-Objekt, das den Request bearbeitet gibt ein Ergebnis
zurück. Abhängig von diesem Ergebnis, können verschiedene JSP die Antwort für den Client erzeugen.
48
2.4 Das Framework Struts
name:
path:
Beschreibt bei welchem durch das Objekt zurückgegebene Ergebnis die JSP aufgerufen wird. Für name=”missingvalue”wird die JSP aufgerufen wenn SignupAction
”missing-value”zurück gibt.
Beschreibt welche JSP aufgerufen werden soll, wenn
das entsprechnde Ergebnis zurückgegeben wurde. Für
path=”/forms/signup.jsp”wird die JSP signup.jsp aufgerufen.
2.4.4 Das Model
Die Komponenten Action und Business Objects bilden das Model. Die ActionObjekte werden mit dem Controller der Anwendung verbunden und haben
auf diese Weise Zugriff auf die Methoden des Servlets. Wenn die Kontrolle
vom Controller an ein Action-Objekt weitergegeben wird, kann das ActionObjekt auf ein im Controller deklariertes ActionForm-Bean zugreifen und so
Informationen weiterleiten. Ein Action-Objekt kann auch Objekte erzeugen
und sie in einer der von Servlets verwendeten Session-Collections ablegen. Da
jeder Client seine eigene Session hat, hat jeder Client auch sein eigenes Bean.
Innerhalb der Session eines Clients kann aber auf das selbe Bean zugegriffen
werden.
Die folgende von der Klasse Action erbende Klasse SignupAction.java überprüft, ob das Eingabefeld firstName leer ist. Für diesen Fall erzeugt sie eine
Nachricht in einem Bean und gibt missing-value zurück. Für den Fall, dass
das Eingabefeld nicht leer ist, wird success zurückgegeben.
package servlets;
import javax.servlet.http.*;
import org.apache.struts.action.*;
public class SignupAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ContactFormBean userBean = (ContactFormBean)form;
String firstName = userBean.getFirstName();
49
Kapitel 2 Grundlagen
if ((firstName==null) || (value.trim().equals(""))) {
makeWarning(request, "first name");
return(mapping.findForward("missing-value"));
}
return(mapping.findForward("success"));
}
protected void makeWarning(HttpServletRequest request,
String message) {
HttpSession session = request.getSession();
ContactFormBean contactFormBean = (ContactFormBean)
session.getAttribute("contactFormBean");
contactFormBean.setWarning(message);
}
}
Die Klasse muss von der Klasse Action erben damit sie mit dem Controller
verbunden werden kann. Außerdem muss die execute Methode überschrieben
werden, die aufgerufen wird, wenn der Controller die Kontrolle an eine Instanz der Klasse weitergibt. Über die an die Methode übergebenen Parameter
kann eine Instanz der Klasse auf Controller und View zugreifen.
public class SignupAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
Die im Controller innerhalb des <action> Tag definierte Aktion ist sowohl
mit der Klasse SingupAction als auch mit einem ContactFormBean verbunden. Deshalb ist die übergebene ActionForm vom Typ ContactFormBean und
kann auf ContactFormBean ”gecastet”werden. Auf das so erhaltene ContactFormBean kann normal zugegriffen werden.
ContactFormBean userBean = (ContactFormBean)form;
String firstName = userBean.getFirstName();
50
2.4 Das Framework Struts
Der erhaltene String wird darauf getestet, ob er leer ist. Für diesen Fall wird
die Methode makeWarning aufgerufen und missing-value zurückgegeben. Für
den Fall, dass der String nicht leer ist, wird success zurückgegeben.
if ((firstName==null) || (value.trim().equals(""))) {
makeWarning(request, "first name");
return(mapping.findForward("missing-value"));
}
return(mapping.findForward("success"));
Die makeWarning Methode benötigt als Parameter nur den request. Damit
kann das oben bereits benutze ContactFormBean erfragt werden und Methoden des Beans aufgerufen werden. Auf diese Weise könnte auch auf andere
Objekte der Session zugegriffen werden (in diesem Fall hätte das ContactFormBean natürlich auch direkt übergeben werden können).
protected void makeWarning(HttpServletRequest request,
String message) {
HttpSession session = request.getSession();
ContactFormBean contactFormBean = (ContactFormBean)
session.getAttribute("contactFormBean");
contactFormBean.setWarning(message);
}
Die Business Objekte liegen außerhalb des Struts Framework. Sie führen in
der Regel Zugriffe auf Datenbanken oder die Berechnung von Funktionen
durch. Da sie auf Java-Klassen basieren, kann alles implementiert werden,
zu dem Java in der Lage ist. Auf Objekte der Komponente wird durch die
Action-Objekte zugegriffen.
2.4.5 Die View
Die View wird durch die Komponenten JSP, Tag Libraries und Action Form
gebildet. Die Komponente JSP wird durch Java-Server-Pages gebildet. Die
Komponente Tag Libraries ist die Tag-Bibliothek von Struts die innerhalb
der JSP benutzt werden kann. Die Komponente Action Form wird durch
Beans gebildet, die von der Klasse ActionForm erben und den Umgang mit
Formularen erleichtern.
51
Kapitel 2 Grundlagen
Java-Server-Page
Eine JSP generiert eine Ausgabe, die als Response an den Benutzer weitergeleitet wird. In der Regel handelt es sich bei der Ausgabe um eine HTML-Seite.
In diesem Beispiel wird beim Aufruf der JSP http://domain/anwendung/actions/signup.jsp eine HTML-Seite erzeugt, die ein Formular enthält. Die
Felder des Formulars werden mit dem Inhalt des in struts-config.xml unter
dem Namen contactFormBean deklarierten ActionForm-Bean gefüllt. Außerdem wird das Attribut warning des contactFormBeans ausgegeben. Der
Inhalt der JSP ist wie folgt:
<!DOCTYPE ...>
<HTML>
<HEAD><TITLE>Sign Up</TITLE></HEAD>
<BODY>
<H1 ALIGN="CENTER">Sign Up</H1>
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<html:form action="/actions/signup">
<bean:write name="contactFormBean" property="warning"
filter="false"/>
First name: <html:text property="firstName"/><BR>
Last name: <html:text property="lastName"/><BR>
Email address: <html:text property="email"/><BR>
<html:submit value="Sign Me Up!"/>
</html:form>
</BODY>
</HTML>
Zuerst wird mit HTML-Tags der Titel der Seite und eine Überschrift definiert.
Dem Compiler der JSP wird die Position der Tag-Library-Descriptor und
mit welchem Präfix sie angesprochen werden bekannt gegeben. In diesem
Fall ”html”für die Tags der HTML-Bibliothek und ”bean”für die Tags der
Bean-Bibliothek von Struts.
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
52
2.4 Das Framework Struts
Es wird das form-Tag der HTML-Bibliothek benutzt. Mit action=”/actions/signup”wird definiert welche (in struts-config.xml ebenfalls definierte) Aktion
durch das Formular ausgelöst werden soll. Die Zeilen:
<html:form action="/actions/signup">
<bean:write name="contactFormBean" property="warning"
filter="false"/>
First name: <html:text property="firstName"/><BR>
Last name: <html:text property="lastName"/><BR>
Email address: <html:text property="email"/><BR>
<html:submit value="Sign Me Up!"/>
</html:form>
werden in der HTML-Ausgabe zu:
<FORM ACTIOM="/actions/signup.do" METHOD="POST">
...
</FORM>
Mit dem Tag write aus der Bean-Bibliothek wird der Inhalt des Attributs
warning des contactFormBean ausgegeben. Das Bean wird automatisch neu
erzeugt,wenn es noch nicht existiert. Existiert bereits ein Bean für den aktuellen Kontext wird dies genutzt. Mit dem Attribut filter kann festgelegt
werden, dass der Inhalt des auszugebenden Attributs nicht gefiltert werden
soll. Normalerweise werden Zeichen wie < durch &lt; ersetzt. Verhindert
werden kann dies durch filter=”false”.
<bean:write name="contactFormBean" property="warning"
filter="false"/>
Mit dem text-Tag aus der HTML-Bibliothek können Eingabefelder definiert
werden. Da die property Attribute mit den Attributen des ActionForm-Bean
ContactFormBean übereinstimmen, werden sie miteinander verbunden. Die
Zeilen:
First name: <html:text property="firstName"/><BR>
Last name: <html:text property="lastName"/><BR>
Email address: <html:text property="email"/><BR>
werden in der HTML-Ausgabe zu Folgendem:
53
Kapitel 2 Grundlagen
First name:
<INPUT TYPE="TEXT" NAME="firstName" VALUE="firstName"><BR>
Last name:
<INPUT TYPE="TEXT" NAME="lastName" VALUE="lastName"><BR>
Email address:
<INPUT TYPE="TEXT" NAME="email" VALUE="email"><BR>
Wobei firstName, lastName und email durch den Inhalt der jeweiligen Beans
ersetzt werden.
Die generierte HTML-Seite wird im Browser des Clients wie folgt dargestellt:
Abbildung 2.15: Die erzeugte HTML-Seite
ActionForm-Bean
Die in der Instanz des ContactFormBean vorliegenden Informationen werden automatisch in die HTML-Seite eingetragen. Der Inhalt des Formulars
54
2.4 Das Framework Struts
wird beim Absenden des Formulars automatisch in die Instanz des ContactFormBean übernommen. Der Quelltext der ContactFormBean Klasse ist wie
folgt:
package servlets;
import org.apache.struts.action.*;
public class ContactFormBean extends ActionForm {
private String firstName = "First name";
private String lastName = "Last name";
private String email = "user@host";
private String warning = "";
public String getFirstName() {return(firstName);}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {return(lastName);}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public String getEmailAddress() {return(emailAddress);}
public void setEmailAddress(String emailAddress) {
this.emailAddress = emailAddress;
}
public String getWarning() { return(warning); }
public void setWarning(String baseWarning) {
this.warning ="Missing " + baseWarning + "<BR>";
}
}
Das Beispiel für den Registrierungsvorgang ist nun komplett und sollte leicht
zu erweitern sein, indem die besprochenen Dateien genutzt werden. Allgemein bietet es sich an, eine vorhandene Struts Anwendung (wie das besprochene Beispiel) zu verändern, um neue Anwendungen zu erstellen. Für die
einfache Bnutzung von Struts bietet es sich an zusätzlich ein Plugin für die
Entwicklungsumgebung seiner wahl zu installieren [11].
55
Kapitel 2 Grundlagen
2.4.6 Das Validator Plugin
Häufig ist es notwendig, nur bestimmte Benutzereingaben in Formularen
zu erlauben. Struts bietet hierfür die Möglichkeit, Eingaben des Benutzers
bereits auf dem Client zu prüfen. Hierfür wird das Validator Plugin genutzt,
welches JavaScript in die generierte HTML-Seite einfügt.
Das Plugin einbinden
Um das Plugin einzubinden, müssen die folgenden Zeilen in die Konfigurationsdatei struts-config.xml eingefügt werden:
...
<plug-in className=
"org.apache.struts.validator.ValidatorPlugIn">
<set-property
property="pathnames"
value=
"/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>
...
Regeln für die Validierung
In der XML-Datei ”validator-rules.xml”werden Regeln für die Validierung
definiert. Struts liefert einige Regeln, die genutzt werden können, bereits
mit. In der XML-Datei ”validation.xml”wird beschrieben, welche Eingaben
für die Formularfelder gültig sind.
<form-validation>
<formset>
<form name="contactFormBean">
<field property="firstName"
depends="required">
<arg0 key="name.displayname"/>
</field>
</form>
</formset>
</form-validation>
56
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
2.5 Lernen von Entscheidungsbäumen und
Assoziationsregeln von Sebastian Heisecke
2.5.1 Einleitung
In der heutigen Zeit ist es durch die Technik, Automatisierung und Computer möglich, Unmengen von Informationen zu erheben, zu sammeln und
zu speichern. Durch diese täglich immer größer werdende Informationsflut
wird es für den Anwender immer schwieriger seine gesuchte Information zu
finden, oder überhaupt einen Überblick über die Daten zu erhalten. Zusammenhänge oder Gesetzmäßigkeiten lassen sich noch viel schwieriger aus den
Daten herausfiltern.
Deswegen verwendet man Data Mining, welches durch Techniken des maschinellen Lernens ein besseres Verständnis von großen Datenmengen ermöglicht,
wobei auch Gemeinsamkeiten und Beziehungen zwischen Daten bzw. Attributen verdeutlicht werden. Entscheidungsbäume und Assoziationsregeln
sind essentielle Bestandteile des Data Mining, wobei dieses besonders häufig
bei der Warenkorbanalyse eingesetzt wird, da besonders Beziehungen und
Gemeinsamkeiten von gekauften Gegenständen interessieren, um mit Kundenprofile den Umsatz durch gezielte Werbung zu erhöhen. Ein bekanntes
Beispiel ist die Internetbuchhandlung Amazon, da hier nach einem Buchkauf, eine Empfehlung von Büchern ausgesprochen wird, die von Kunden
stammt, die das gleiche Buch gekauft haben.
57
Kapitel 2 Grundlagen
2.5.2 Grundlagen
Entscheidungstabellen
Eine Entscheidungstabelle ist die einfachste und elementarste Darstellung
von Daten, die sowohl als Ein- als auch als Ausgabe für das Data Mining
genutzt werden kann.
Die unten angegebene Tabelle gibt anhand von Wetterdaten darüber Auskunft, ob zum Beispiel ein Fußballspiel gespielt werden kann oder nicht. Hierbei sind die Wetterdaten die Attribute, welche in den ersten vier Spalten zu
erkennen sind. Eine Zeile der Tabelle enthält für jedes Attribut einen Wert
und ordnet diese Attributkombination einer Klasse zu, die in Spalte fünf angegeben wird. Die Klasse gibt über die Entscheidung Auskunft, ob ein Spiel
stattfindet oder abgesagt wird. Im Beispiel mit den Wetterdaten wären 36
Attributkombinationen möglich, von denen 14 in der Entscheidungstabelle
aufgeführt sind.
Abbildung 2.16: Entscheidungstabelle für die Wetterdaten
Entscheidungsbäume
Ein elementarer Bestandteil des maschinellen Lernens sind Entscheidungsbäume. Im Gegensatz zu Entscheidungstabellen bieten sie eine strukturierte Beschreibung von Daten, die für viele Aufgabenstellungen eine leichter
verständliche Darstellung der zugehörigen Regeln ermöglichen, da Bäume
gut visualisiert werden können.
Beim Data Mining dienen Entscheidungsbäume zur Bestimmung der Klassenzugehörigkeit von Daten, wobei ein zu klassifizierender Datensatz von
der Wurzel bis zu einem Blatt den Baum durchläuft. An jedem Knoten wird
ein bestimmtes Attribut überprüft und abhängig vom Ergebnis entweder
der linke oder rechte Sohn zur weiteren Überprüfung gewählt. babei wird
ein Attribut meistens mit einem Konstanten Wert verglichen (größer, gleich,
kleiner) was eine ja/nein Entscheidung liefert.
Knoten können auch mehrfache Verzweigungen aufweisen, wenn zum Beispiel das Attribut numerisch ist. Bei einem Vergleich von kleiner, gleich und
größer würde zum Beispiel eine Dreifachverzweigung entstehen. Ebenso wenn
Intervalle, wie zum Beispiel unterhalb, innerhalb und oberhalb, verglichen
58
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
werden. Auch wenn man das Fehlen eines Wertes als eigenständigen Attributwert aufnimmt, ergibt sich eine Anzahl von Verzweigung die größer als
zwei ist.
Wenn die Instanzen eines Datensatzes von ihrem Weg beginnend bei der
Wurzel ihre jeweiligen Blätter erreicht haben, so ist dieser Datensatz klassifiziert worden, da die Instanzen den Klassen der jeweiligen Blätter zugeordnet
werden können.
Ferner ist es auch ohne große Umstände möglich, einen Entscheidungsbaum
in eine Regelmenge umzuwandeln, was im Anschluss präzisiert wird.
Ein weiterer elementarer Bestandteil des maschinellen Lernens sind Klassifi-
Abbildung 2.17: Entscheidungsbaum für die Wetterdaten
kationsregeln. Ein weiterer Vorteil von Regeln ist die Tatsache, das jede einzelne Regel als eine Art unabhängiger ”Wissens-Baustein” betrachtet werden
kann. Zudem sind bereits vorhandene Regelmengen leicht erweiterbar ohne
die existierenden Regelen zu verfälschen, wohingegen eine Erweiterung der
Baumstruktur diese unbrauchbar machen kann.
In Abschnitt 2.1 wurden bereits die Entscheidungstabellen vorgestellt, wobei aus diesen direkt Klassifikationsregeln abgelesen werden können. Nimmt
man zum Beispiel die erste Zeile der Entscheidungstabelle und verknüpft
die Attribute mit einem ”und”, dann erhält man eine Regel, die diese Werte der Attribute einer Klasse zuordnet und somit klassifiziert. Wenn also
alle booleschen Bedingungen den Wert ”true” zurückgeben, gilt die Regel.
59
Kapitel 2 Grundlagen
Die Bedingungen in den Regeln werden somit immer mit ”und” Verknüpft,
während die Regeln selber per ”oder” Verknüpft werden.
Beispiel 1. If outlook = sunny and temperature = hot and humidity = high
and windy = false then play = no
Diese Klassifikationsregel ist zwar korrekt, bietet aber kaum einen Vorteil
gegenüber der Entscheidungstabelle. Sollte es allerdings möglich sein einige
Attribute aus der Regel zu streichen, können mehrere Zeilen der Entscheidungstabelle durch eine Klassifikationsregel dargestellt werden. Lässt man
aus obiger Regel temperature und windy wegfallen, erhält man eine Klassifikationsregel die neben der ursprünglichen Kombination von Attributwerten
auch die Zeile 2 und 8 der Entscheidungstabelle richtig klassifiziert.
Beispiel 2. If outlook = sunny and humidity = high then play = no
Es muss aber beachtet werden, das je mehr Bedingungen in einer Regel weggelassen werden, die Gefahr steigt, dass einige Instanzen falsch klassifiziert
werden.
Klassifikationsregeln lassen sich aber auch anders erzeugen, indem ein Entscheidungsbaum in eine Regelmenge umgewandelt wird. Dies wird erreicht
indem für jedes Blatt des Baumes eine Regel angelegt wird. Die Bedingungen
der einzelnen Regeln erhält man, indem man den Baum von der Wurzel bis
zum gewünschten Blatt durchläuft und jeden Knoten der auf diesem Pfad
liegt als neue Bedingung in die Regel aufnimmt. Das Blatt bestimmt dann
die Klasse, der die Attributkombination zugeordnet werden können. Die einzelnen Regeln werden mit oder verknüpft, sodass der Regelblock den Baum
ersetzen kann.
Ein Nachteil dieser Methode ist jedoch, dass die Regeln die aus Bäumen
erzeugt wurden meistens komplizierter als nötig sind. Dafür können keine
Regeln auftreten die der gleichen Instanz unterschiedliche Klassen zuordnen,
weil die Redundanz in der Regelstruktur Mehrdeutigkeiten bei der Interpretation verhindert. Auch wird bei aus Bäumen abgelesenen Regeln jede
Instanz wirklich klassifiziert.
Klassifikationsregeln sind ein elementarer Bestandteil des Data Mining, da
sie die Grundlage für die Assoziationsregeln bilden und somit erst das maschinelle Lernen und das Vorhersagen von Attributwerten ermöglichen.
Assoziationsregeln
Wie zuvor schon erwähnt sind Assoziationsregeln verwandt mit den Klassifikationsregeln. Der einzige Unterschied besteht darin, dass nicht nur Klassen,
60
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
sondern auch beliebige Attributwerte und Attributkombination vorhergesagt
werden können. Somit dienen Assoziationsregeln der Darstellung verschiedener Regelmäßigkeiten, die in der Datenmenge zu finden sind. Sie sagen im
Allgemeinen unterschiedliche Attributkombinationen voraus, so dass wesentlich mehr Assoziationsregeln als Klassifikationsregeln aus einem Datensatz
erzeugt werden können.
Zur Veranschaulichung dienen die bereits bekannten Wetterdaten zur Beurteilung, ob gespielt werden kann oder nicht. Die folgenden Beispiele sind
besonders gut, weil sie für die gesamten Trainingsdaten zutreffen:
Beispiel 3. If temperature = cool then humidity = normal
Beispiel 4. If outlook = sunny and play = no then humidity = high
Beispiel 5. If windy = false and play = no then outlook = sunny and humidity = high
Assoziationsregeln ermöglichen durch das Aufdecken von Regelmäßigkeiten
das Vorhersagen von Attributwerten. Wie das Beispiel 2.4.1 zeigt, tritt, immer wenn temperature = cool ist, humidity = normal auf. Somit kann man
bei einem anderen Datensatz, wo der Wert des Attributs humidity fehlt,
aber der Wert des Attributs temperature = cool ist, diesen fehlenden Wert,
nämlich humidity = normal, hinzufügen.
Die Beispiele 2.4.2 und 2.4.3 zeigen, das auch Attributkombinationen zur Vorhersage genutzt, aber auch selbst vorhergesagt werden können. Somit lassen
sich auch mehrere Assoziationsregeln zu einer komplexeren zusammenfassen
oder, wie Beispiel 2.3.2 und 2.4.2 zeigen, können auch häufig die Attribute
innerhalb der Regel umgestellt werden. Bei Letzteren ist immer Vorsicht geboten und sollte stets anhand der Trainingsdaten validiert werden.
Bei den zuvor gezeigten Beispielen wurde bereits erwähnt, dass diese zu 100
Prozent in Bezug auf die Trainingsdaten korrekt sind. Dies wird bei Assoziationsregeln als Genauigkeit bezeichnet. Die Genauigkeit ist die Anzahl der
Instanzen, die sie korrekt vorhersagt, ausgedrückt als Proportion aller Instanzen, auf die sie angewendet wird.
Anzahl der richtig klassifizierten Instanzen
Genauigkeit =
Anzahl aller Instanzen
61
Kapitel 2 Grundlagen
2.5.3 Algorithmen
Algorithmus zum Erzeugen von Entscheidungsbäumen
Der Algorithmus zum Erzeugen von Entscheidungsbäumen baut auf dem
”Teil- und Hersche” Verfahrensprinzip auf und ist einer der wesentlichen Bestandteile des Data Mining, da dieser Algorithmus in der Lage ist Entscheidungsbäume aufzubauen. Es folgen nun die einzelnen Schritte zum Aufbau
eines Entscheidungsbaumes.
Am Anfang steht die Wurzel des Baumes, so dass ein Attribut als Wurzelknoten ausgewählt werden muss. Die Werte, die das Attribut annehmen kann,
bilden die Verzweigungen, die vom Wurzelknoten ausgehen.
Es stellt sich als erstes die Frage, welches der Attribute am besten als Wurzelknoten geeignet ist. Auf das Beispiel mit den Wetterdaten aus den vorherigen
Kapiteln angewendet bedeutet dies, dass es vier Attribute und somit vier potentielle Wurzelknoten gibt. In Abbildung 3.1.1. sind diese abgebildet, wobei
die Blätter die yes- und no-Klassen darstellen. Treten entweder nur yes- oder
no-Klassen in einem Blatt auf, braucht dieses nicht weiter unterteilt zu werden.
Um beurteilen zu können welches Attribut die reinsten Unterknoten erzeugt,
benötigen wir ein Maß, welches dieses angibt. Hierzu wird das Informationsmaß eingeführt, welches in bits gemessen wird. Bits sind nicht mit der
Speichereinheit bit zu verwechseln, da das Informationsmaß häufig Werte
zwischen 0 und 1 annimmt. Die Einzelheiten zur Berechnung folgen im nächsten Abschnitt.
Rechnet man nun für jede Verzweigung des Wurzelknotens aus Abbildung
3.1.1 das Informationsmaß aus, so ist man in der Lage das durchschnittliche
Informationsmaß für den Wurzelknoten auszurechnen. Berechnet man ebenfalls das Informationsmaß der unstrukturierten Trainingsdaten, ist es auch
noch möglich den Informationsgewinn auszurechnen. Dazu wird das Informationsmaß des Wurzelknoten vom Informationsmaß der unstrukturierten
Trainingsdaten subtrahiert.
Anhand des Maßes für den Informationsgewinn, lassen sich nun die verschiedenen Attribute auf ihre Fähigkeit als Wurzelknoten beurteilen. Das Attribut
mit dem höchsten Informationsgewinn bildet den Wurzelknoten. Die Werte,
die das Attribut annehmen kann bilden die Verzweigungen. Im folgenden Beispiel wurde outlook als Zerlegungsattribut für die Baumwurzel ausgewählt.
Damit sind die Trainingsdaten in Untermengen zerlegt, eine für jeden Wert,
den das Attribut outlook annehmen kann. Diese eben beschriebene Vorgehensweise kann rekursiv für jede Verzweigung ausgeführt werden, wobei nur
jene Instanzen verwendet werden, die die Verzweigung auch erreichen.
62
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
Abbildung 2.18: Auswahl des Wurzelknoten
Da eine erneute Zerlegung nach outlook keinen Sinn ergibt, werden nur noch
die drei restlichen Attribute berücksichtigt. Abbildung 3.1.2 zeigt die möglichen Tochterknoten vom Wurzelknoten für den Attributwert outlook = sunny. Es wird wieder der Informationsgewinn ausgerechnet und mit diesem das
Attribut für den Knoten ausgewählt. In diesem Fall ist es humidity.
Mit diesem Schritt ist der sunny-Zweig abgearbeitet, weil in den TöchterKnoten des Knotens humidity alle Instanzen dieselbe Klasse, hier also yes
bzw. no, aufweisen. Laut Teile und Herrsche Algorithmus zeigt dies das Ende der Konstruktion eines Baumabschnittes an. Auch der overcast-Zweig
ist schon abgearbeitet, da er von Anfang an rein war und nur yes-Klassen
enthält. Als letztes muss der rainy-Zweig abgearbeitet werden.
Wendet man nun wieder den Algorithmus rekursiv auf den rainy-Zweig an,
so erhält man den in Abbildung 2.2.1 gezeigten Entscheidungsbaum. In der
Praxis kommt der Idealfall reine Knoten zu haben, um somit ein Blatt bilden
zu können, nur sehr selten vor. Somit ist es schwer die Abbruchbedindgung
zuerreichen, damit der Algorithmus terminiert. In der Theorie wird der Prozess beendet, wenn die Daten nicht weiter zerlegbar sind. In der Praxis wird
mit Prunning diese Problem bewältigt.
63
Kapitel 2 Grundlagen
Abbildung 2.19: Auswahl des Tochterknoten
Informationsmaß
Das Informationsmaß ist das entscheidene Maß für den Teile und Hersche
Algorithmus, da es eine Aussage über die Eignung von verschiedenen Attributen als Knoten ermöglicht.
Wie zuvor erwähnt wird das Informationsmaß in bits gemessen und nimmt
Werte zwischen 0 und 1 an. Es wird mit Hilfe der Entropie berechnet, welche
mit dem Logarithmus zur Basis 2 arbeitet. Folgende Formel gibt die Berechnung des Informationsmaßes für eine Datenmenege mit drei Klassen an.
Wobei p,q,r für die Anzahl der Instanzen, die zu dieser Klasse gehören steht.
Die Formel ist für weniger oder mehr Klassen einfach erweiterbar. Beispiel
3.2.1 zeigt die Berechnung für zwei Klassen bei den Wetterdaten. Beispiel
3.2.2 hingegen veranschaulicht die Bedeutung des Informationsmaßes innerhalb des Algorithmus zur Erzeugung von Entscheidungsbäumen.
Formel 3.2.1
info([p,q,r]) = entropy(p / (p + q + r), q / (p + q + r), r / (p + q + r))
= [- p log p - q log q - r log r + (p + q + r) log (p + q + r)] / (p + q + r)
Beispiel 3.2.2
Info(2,3) = (-2 log 2 – 3 log 3 + 5 log 5) / 5 = 0,971
64
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
Abbildung 2.20: Informationsmass
65
Kapitel 2 Grundlagen
Der Abdeckungs-Algorithmus
Für die Konstruktion von Regelen könnte man natürlich erst einen Entscheidungsbaum erzeugen und von diesem dann die Regeln ableiten. Wenn
allerdings effiziente Regeln erzeugt werden sollen, ist dieses sehr schwer und
bedarf einen großen Aufwand. Deswegen lohnt sich ein alternativer Ansatz:
Der Abdeckungs-Algorithmus.
Dieser Ansatz basiert darauf, die einzelnen Klassen nacheinander zu betrachten und nach einer Möglichkeit zu suchen, alle darin enthaltenen Instanzen
abzudecken und gleichzeitig Instanzen auszuschließen, die nicht zu der Klasse gehören. Der Name Abdeckungs-Algorithmus bezieht sich auf die Eigenschaft, dass in jedem Schritt eine Regel abgeleitet wird, die einige der Instanzen abdeckt.
Zum besseren Verständnis des Abdeckungsalgorithmus soll Abbildung 3.3.1
dienen, da in einem zweidimensionalen Instanzenraum der Abdeckungs Algorithmus graphisch dargestellt werden kann. Es wird eine Regel gesucht, die
alle a’s abdeckt und die b’s ausschließt.
Als erstes wird eine vertikale Zerlegung des Instanzenraumes durch die Regel
if x > 1.2 then class = a vorgenommen. Durch diese Regel werden neben allen
a’s aber auch noch fünf b’s abgedeckt, so dass der Regel noch eine Bedingung
hinzugefügt werden muss, um eine 100 prozentige Abdeckung zu erreichen.
Indem eine horizontale Zerlegung vorgenommen wird, ist es mit der Regel if
x > 1.2 and y > 2.6 then class = a möglich alle a’s abzudecken und die b’s
auszuschließen.
Natürlich lässt sich der Algorithmus auch allgemein gültig beschreiben. Der
Abbildung 2.21: Darstellung des Abdeckungsalgorithmus
Algorithmus ergänzt jede Regel solange mit Bedingungen bis ihre Genauigkeit 100 Prozent erreicht. Die Genauigkeit berechnet sich aus p, der Anzahl
der positiven Beispiele die die Regel richtig abdeckt, dividiert durch t, der
66
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
Anzahl der Instanzen die die Regel insgesamt abdeckt. Wenn p = t ist, beträgt die Genauigkeit 100 Prozent, da die Anzahl der Instanzen auf die die
Regel zutrifft gleich der Zahl der Instanzen ist, die die Regel abdeckt.
Der Algorithmus iteriert mit der äußeren Schleife über alle Klassen, es werden also nacheinander für jede Klasse Regeln erzeugt, die die Beispiele dieser
einen Klasse abdecken. Bei jedem Schleifendurchlauf werden die Trainingsdaten bzw. die Instanzmenge neu initialisiert, mit einer leeren Regel, die noch
alle Beispiele der Trainingsdaten abdeckt. Diese wird durch eine Bedingung
erweitert, so dass möglichst viele positive Beispiele der Klasse durch die Regel abgedeckt werden. Daher wird die Bedingung gewählt, die das Verhältnis
p/t maximiert. Die Beispiel die durch die Regel abgedeckt werden, werden
aus der Beispielmenge entfernt.
Nach der gleichen Vorgehensweise wie zuvor, werden weitere Bedingung der
Regel hinzugefügt, bis ihre Genauigkeit 100 Prozent erreicht, also alle positive Beispiele abgedeckt sind, aber auch nur diese.
Wenn die Regel für eine Klasse korrekt erstellt worden ist, geht der Algorithmus zur nächsten Klasse. Da zuvor die positiven Bespiele der vorherigen
Klasse entfernt worden sind, muss der Instanzenraum neu initalisiert werden.
Algorithmus zur Erzeugung von Assoziationsregeln
Es stellt sich noch die Frage wie man Assoziationsregeln erzeugt. Da bereits
bei kleinen Datenmengen Unmengen von Assoziationsregeln möglich sind,
interessieren nur Assoziationsregeln, die eine hohe Abdeckung aufweisen. Es
wird nun nicht mehr zwischen linker und rechter Regelseite unterschieden,
sondern nach Kombinationen von Attribut-Wertepaaren gesucht, die eine
vorgegebene Mindestabdeckung von Instanzen aufweisen.
Diese Kombinationen werden auch als Gegenstandsmengen bezeichnet, da
ein Attribut-Wertepaar ein Gegenstand ist. Die Bezeichnung leitet sich aus
der Warenkorbanalyse ab, wo nach Assoziationen zwischen Gegenständen,
sprich den gekauften Artikel, gesucht wird.
Der Algorithmus zur Erzeugung von Assoziationsregeln arbeitet in zwei Phasen, wobei in der ersten Phase Gegenstandsmengen mit einer geforderten
Mindestabdeckung erzeugt werden. Dies erreicht man, indem bei jeder Operation die Datenmenge durchlaufen wird, um die Gegenstände in jeder Menge zu zählen. Diese nach einem Durchlauf entstanden Gegenstandsmengen,
werden in einer Tabelle gespeichert, wie es in Abbildung 3.4.1 in der ersten
Spalte zu erkennen ist.
Aus diesen so genannten Ein-Gegenstandsmengen (da sie einen Gegenstand
enthalten) lassen sich nun potentielle Zwei-Gegenstandsmengen durch Kombination von Ein-Gegenstandsmengen erzeugen. Dabei ist zu beachten, dass
67
Kapitel 2 Grundlagen
Attribute des gleichen Typs mit unterschiedlichen Werten nicht kombiniert
werden dürfen, da so etwas in der realen Welt nicht existiert. Diese ZweiGegenstandsmengen müssen nun noch auf ihre Abdeckung bezüglich der
Datenmenge überprüft werden, wobei die Zwei-Gegenstandsmengen, die die
Mindestabdeckung nicht erfüllen aus der Tabelle gelöscht werden. So erhält
man die zweite Spalte in Abbildung 3.4.1.
Iterativ ist es möglich, aus den Zwei-Gegenstandsmengen nach der zuvor
beschriebenen Arbeitsweise Drei-Gegenstandsmengen usw. zu erzeugen. Für
dieses Beispiel ist damit die erste Phase des Algorithmus zur Erzeugung von
Assoziationsregeln abgeschlossen.
Allgemein gilt, dass nur aus Gegenstandsmengen die bereits die Mindestabdeckung erfüllen, höherwertige Gegenstandsmengen generiert werden können,
die auch die Mindestabdeckung erfüllen. Ferner können keine Gegenstandsmengen erzeugt werden, die mehr Gegenstände aufweisen, als es Attribute in
der Datenmenge gibt, da sonst zwangsläufig Gegenstände mit unterschiedlichen Werten eines gleichen Attributs in einer Gegenstandsmenge existieren
würden. In unserem Beispiel ist somit die Vier- Gegenstandsmenge die höchst
mögliche Gegenstandsmenge.
In der zweiten Phase des Algorithmus zur Erzeugung von Assoziations-
Abbildung 2.22: Gegensandstabelle der Wetterdaten
regeln werden aus jeder Gegenstandmenge die Regeln mit der geforderten
Mindestabdeckung herausgefiltert. Um Regeln zu erzeugen, die nur eine Auswertung auf der rechten Seite haben, ist es ausreichend, eine Bedingung nach
der anderen als Schlussfolgerung der Regel in Betracht zu ziehen, sie aus der
Gegenstandsmenge zu entfernen und die Abdeckung der gesamten Gegenstandsmenge durch die Abdeckung der resultierenden Teilmengen zu teilen,
so dass das Ergebnis die Genauigkeit der Regel angibt.
Möchte man Regeln mit Mehrfachauswertungen, wäre es äußert Rechenintensiv zu überprüfen, welche Wirkung es hat, jede Teilmenge der Gegenstandsmenge auf die rechte Seite der der Regel zu stellen und den Rest der
Menge als Bedingungen stehen zu lassen. Dies wäre zwar die logische Vorgehensweise, ist aber, außer bei kleinen Datenmenge, zu aufwändig.
Deswegen ist es günstiger, Regeln mit einfachem Schluss, die wie eben gezeigt leicht erzeugt werden können, zu potentiellen Regeln mit doppeltem
Schluss umzuformen. Regeln mit doppeltem Schluss lassen sich zu potentiellen Regeln mit dreifachem Schluss umformen. Im Prinzip handelt es sich um
die gleiche Vorgehensweise wie beim Erzeugen der potentiellen Gegenstandsmengen. Natürlich muss jede potentielle Regel mit der Tabelle abgeglichen
68
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
werden, um sicher zugehen, dass die Forderung nach einer bestimmten Mindestgenauigkeit erfüllt wird. Dies ist aber weniger aufwändig, als die Regeln
durch die zuvor angedeutete Brute-Force-Methode zu erzeugen.
69
Kapitel 2 Grundlagen
2.5.4 Optimierung
Prunning
Wie bereits erwähnt ist es selten, dass ein Blatt zu 100 Prozent rein ist und
somit die gewünschte Abbruchbedingung liefert. Häufig ist es deshalb sinnvoll, schon früher aufzuhören oder nachträglich den Baum zu bescheiden,
auch Prunning genannt.
Man unterscheidet zwischen pre-, also beschneiden während des Erzeugen
des Baumes, und post-prunning, beschneiden nach Erstellen des Baumes.
Bei Pre-Prunning läßt sich vorher nicht abschätzen, ob dies eine Verbesserung mit sich bringt, da zum Beispiel Knoten, die mit dem zu beschneidenen
Knoten im Zusammenhang stehen, erst später dem Baum hinzugefügt werden können. Damit besteht die Gefahr des Informationsverlusts, wenn man
den Knoten beschneidet. Deswegen steht auch das Post-Prunning im Vordergrund.
Beim Post-Prunnig wird zuerst der Baum vollständig mit dem bekannten Algorithmus zur Erzeugung von Entscheidungbäumen aufgebaut. Erst jetzt beginnt man mit dem Prunning. Zum einem erschweren replizierte Unterbäume,
also Bäume die mehrfach an verschiedenen Stellen des Baumes zu finden
sind, das Verständis, so dass hiervon einige aus dem Baum entfernt werden
können. Wobei aber keine festen Kriterien vorgegeben sind, wann man einen
replizierten Unterbaum löschen darf. Hier muss vor allem der Autor darauf
achten, ob das Löschen eines replizierten Unterbaumes nicht die Aussagekraft des Baumes zerstört.
Zum anderen sind Unterbäume unerwünscht, in denen fast alle Instanzen der
gleichen Klasse angehören, aber einige Ausreißer, die zu einer anderen Klasse gehören, somit diesen Unterbaum bedingen. Mit Pruning schneidet man
den Unterbaum vom Baum ab und ersetzt diesen dann durch ein Blatt der
Klasse, der die Mehrheit der Instanzen des Unterbaumes angehören. Dieses
subtree replacement kann man auch automatisch vornehmen lassen, in demman eine Bedingung für das Pruning angibt. Zum Beispiel wenn 99 Prozent
aller Instanzen eines Baumes zu einer Klasse gehören und mehr als 100 000
Instanzen vorliegen, so wird der Unterbaum durch ein Blatt erstezt.
Natürlich geht Genauigkeit verloren, wenn man Unterbäume aus dem Baum
entfernt, aber dadurch wird die Verständlichkeit und Handhabbarkeit um ein
beträchtliches erhöht. Ferner lässt sich durch eine Testmenge, die man auf
den Baum ansetzt, herausfinden welche Unterbäume ersetzt werden können.
Abbildung 4.1.1 zeigt die Vorgehensweise, wobei aber beachtet werden muss,
dass in der Realität weit aus mehr Instanzen der Klasse No angehören müssten, um an dieser Stelle ein so genanntes subtree-replacement vorzunehmen.
70
2.5 Lernen von Entscheidungsbäumen und Assoziationsregeln
Abbildung 2.23: Subtree-Replacement
Evaluation
Beim maschinellen Lernen ist es vom besonderen Interesse Zusammenhänge
und Gesetzmäßigkeiten zu finden, und Regeln abzuleiten und Vorhersagen
treffen zu können. Da man diese Regeln aus relativ kleinen Datensätzen
erzeugt, ist es von außerordenlicher Wichtigkeit, seine Ergebnisse zu überprüfen. Denn die Gefahr besteht, das einige Sonderfälle falsche Regeln erzeugt haben können.
Zur Überprüfung der Ergebnisse kann man nun die Daten nehmen, die man
nicht zum Lernen verwendet hat. Beim Beispiel mit den Wetterdaten hatten
wir nur 14 von 36 Instanzen benutzt, so dass die restlichen 22 als Testmenge
genutzt werden können. Möchte man Regeln überprüfen, so gibt die Anwendung dieser auf die Testmenge durch ihre Genauigkeit darüber Aufschluß,
wie gut die Regeln die Testmenge klassifizieren.
Bei Bäumen hingegen wird die Testmenge auch als Prunningmenge bezeichnet. Denn wenn man die Testmenge durch den zuvor erstellten Entscheidungsbaum laufen läßt, können nicht oder kaum benutzte Verzweigungen
erkannt werden, die zum Beispiel durch Sonderfälle entstanden sind. Durch
Subtree-Replacement können dann die Bäume optimiert werden, um ein
höheres Verständnis durch weniger Komplextität zu gewährleisten.
71
Kapitel 2 Grundlagen
2.5.5 Schlusswort
In einer Welt in der das Wissen und die Verfügbarkeit von Informationen
immer wichtiger werden, steigt auch gleichzeitig die Bedeutung von Data
Mining Techniken. Somit sind Entscheidungsbäume und Assoziationsregelen
elementarer Bestandteil der heutigen ”digitalen” Gesellschaft geworden. Wobei diese Entwicklung sich im Hintergrund vollzogen hat, denn Data Mining
Techniken stellen nur wenig neue Funktionalitäten zur Verfügung, da ihre
eigentliche Aufgabe die Analyse, Strukturierung und Veranschaulichung von
riesigen Datenmengen ist, die sonst nur schwer oder gar nicht zu handhaben
wären.
Dies findet vor allem Einsatz bei der Kundenanalyse, wo riesige Datenmengen über das Einkaufsverhalten gesammelt werden und man an Zusammenhängen von gekauften Gegenständen interessiert ist, die so nicht aus der
Datenflut abzulesen wären.
Die Assoziationsregeln sind vor allem auf der technischen Seite interessant, da
durch sie schon bei wenigen vorliegenden Daten Rückschlüsse auf andere Daten ermöglicht werden. Dies ist zum Beispiel bei Amazon zu finden, wo einem
nach einem Kauf ein ähnliches Buch vorgestellt wird. Je mehr man kauft und
je mehr Daten somit zugrunde liegen, desto besser werden die Schlüsse. Assoziationsregeln sind bei der Implementierung deshalb so beliebt, da sie ganz
einfach umzusetzen sind. Ihr Nachteil ist, dass sie für Laien und Außenstehende schwer verständlich sind. Im Gegensatz zu Entscheidungsbäumen, die
sich nur schwer implementieren lassen, aber dafür sofort für jeden verständlich sind. Gerade für Präsentationen von Ergebnissen des Data Minings sind
sie hervorragend geeignet, denn sie stellen Zusammenhänge, Regeln und die
Struktur der Daten für jeden verständlich dar.
72
2.6 Lineare und logistische Regression - Modell und Lernverfahren
2.6 Lineare und logistische Regression - Modell
und Lernverfahren von Daniel Meyerholt
2.6.1 Einleitung
Für das Data-Mining sind Methoden zur Vorhersage von Werten und zur
Klassifizierung von Testdaten sehr wichtig. Sie helfen, Daten einzuordnen
und eine gewisse Struktur in diese zu bringen.
Regressionsverfahren sind hierbei aus der Statistik anerkannte Verfahren die
helfen, numerische Voraussagen zu treffen. Modell- und Regressionsbäume
stellen ein maschinelles Lernverfahren dar und helfen die Qualität von Vorhersagen oder Klassifizierungen zu verbessern und zu strukturieren.
Als Grundlage für diese Ausarbeitung dienten mir die entsprechenden Kapitel (4.6 und 6.5) aus [?] für die Abschnitte über lineare Regression und Modellbäume. Der Teil über logistische Regression basiert auf einer Veröffentlichung von Rainer Diaz-Bone [?].
2.6.2 Lineare Regression
Grundlagen
Die lineare Regression ist ein Verfahren aus der klassischen Statistik, was
dazu dient, numerische Voraussagen über eine (abhängige) Variable zu treffen, in dem diese von verschiedenen anderen (unabhängigen) Variablen (bzw.
Attributen) geschätzt wird. Sie hat die Prämisse, dass zwischen diesen Variablen und der abhängigen ein linearer Zusammenhang besteht.
Das lineare Modell
Das lineare Modell eignet sich auch sehr gut dazu, bestimmten numerischen
Attributwerten eine numerische Klasse zuzuordnen. Den linearen Zusammenhang beschreibt man durch:
x = w0 + w1 a1 + w2 a2 + ... + wk ak
x ist die Klasse, k die Anzahl der Attribute, a1 . . . ak die Attributwerte und
w0 . . . wk die Gewichtungen für die entsprechenden Attributwerte. w0 kann
man sich hierbei als eine Art “y-Achsenabschnitt” vorstellen, wie dies z.B.
auch bei einer normalen Geradengleichung der Fall ist. Zur Notation ist es
73
Kapitel 2 Grundlagen
sinnvoll, das Attribut a0 einzuführen, das immer den Wert 1 hat. Damit lässt
sich die Formel umschreiben zu:
x=
k
X
wj aj
j=0
Bestimmung der Gewichtungen
Nun hängt die Qualität einer solchen Vorhersage offensichtlich sehr stark
von der Wahl der Gewichtungen ab. Diese erhält man, indem man eine gewisse Anzahl Trainingsdaten vorliegen hat, deren Klasse bekannt ist, und
aus diesen mit Hilfe eines Optimierungsverfahrens geeignete Gewichtungen
bestimmt.
Die vorhergesagte Klasse für den i. Trainingsdatensatz wird ausgedrückt als:
k
X
(i)
wj aj
j=0
Die bekannte Klasse des i. Trainingsdatensatzes beschreibt man als x(i) .
Y
#
"#
"
%
!
!
!
!
+
$%
*+
$
*
'
&'
&
X
)
()
(
Abbildung 2.24: Trainingsdatensätze
Im einfachen Beispiel lässt sich dies durch eine “Punktwolke” wie in Abb.
2.24 darstellen. Die blauen Punkte stellen die Trainingsdatensätze dar, wobei
die x-Achse die unabhängige und die y-Achse die entsprechenden abhängigen
Werte beschreiben. Es ist schon so zu erkennen, dass zwischen den Daten ein
linearer Zusammenhang besteht.
74
2.6 Lineare und logistische Regression - Modell und Lernverfahren
Die Gewichtungen bzw. Regressionskoeffizienten müssen nun in einem Verfahren so gewählt werden, dass die vorhergesagte Klasse einer Trainingsinstanz möglichst dicht an der echten Klasse liegt. Diese “Nähe” beschreibt
man einfach als Differenz zwischen diesen Werten:
x
(i)
k
X
−
(i)
wj aj
j=0
In Abb. 2.25 ist dies wieder im einfachen Fall dargestellt, wo es nur eine
Gewichtung zu finden galt. Die entstandene Gleichung ist durch die grüne
Linie angedeutet. Die rote Linie stellt den zu minimierenden Wert für einen
Trainingsdatensatz dar.
Y
#
"#
"
%
!
!
!
!
+
$%
*+
$
*
'
&'
X
&
)
()
(
Abbildung 2.25: Trainingsdaten mit gefundener Gleichung
In der Praxis verwendet man zur Bestimmung der Koeffizienten die Methode
der kleinsten Quadrate. Die Bewertung der Güte einer Koeffizientenkombination erfolgt mit folgendem Ausdruck:
n
X
i=1
x(i) −
k
X
!2
(i)
wj aj
j=0
Das Ziel ist es also, diese Summe durch geeignete Wahl der Koeffizienten
zu minimieren. Abbruchkriterien für Algorithmen, die “gute” Koeffizienten
bestimmen könnten sind zum Beispiel ein bestimmter Grenzwert für die Bewertungsfunktion sein oder auch ein sich nicht änderndes Muster in einer
Folge von Bewertungen also keine große Besserung durch Veränderung der
Koeffizienten. Ein sehr einfaches Verfahren stellt zum Beispiel das Gauss’sche
Eliminationsverfahren dar.
75
Kapitel 2 Grundlagen
Problematisch ist allgemein bei solchen Verfahren jedoch das Verhalten, wenn
die Trainingsdaten viel “Rauschen” bzw. “Ausreißer” beinhalten. In Abb.
2.26 wird deutlich, wie ein solcher Ausreißer (roter Punkt) die Qualität des
ganzen Modells verschlechtert.
Y
#
"#
"
%
!
!
!
!
+
$%
*+
$
*
'
&'
X
&
)
()
(
-
,-
,
Abbildung 2.26: Verhalten auf Ausreißer
Klassifizierung
Die lineare Regression wird auch zum Klassifizieren von Daten in Klassen
verwendet. Da sie an sich numerische Werte vorhersagt, die jeden Wert von
−∞ . . . + ∞ annehmen können, ist das Klassifizieren so nicht direkt möglich.
Eine Möglichkeit ist die sogenannte “lineare Regression mit Mehrfachantworten”. Hier wird ein Regressionsmodell für jede Klasse erstellt, wobei der
entstandene Wert zwischen 0 und 1 liegen soll. 0 bedeutet dann “gehört”
nicht zu der Klasse” und 1 entsprechend “gehört zu der Klasse”. Die so entstandenen Regressionsfunktionen lassen sich auch als Mitgliedsschaftsfunktionen für jede Klasse auffassen. Hat man nun einen Testvektor, so werden
dessen Attribute in jeder dieser Funktionen eingesetzt und dann das Modell
ausgewählt, dass den größten Wert (nahe 1) annimmt. Der Testvektor ist
dann wahrscheinlich in eben dieser Klasse.
Vor- und Nachteile
Die Vor - und Nachteile des linearen Regressionsmodells sind gegeneinander
abzuwägen. Vorteile sind:
76
2.6 Lineare und logistische Regression - Modell und Lernverfahren
• Es ist einfaches Modell, das gut im Rechner umzusetzen ist9
• Bei gesichertem linearen Zusammenhang liefert es qualitativ gute Ergebnisse.
Es hat aber auch Nachteile:
• Linearer Zusammenhang ist oft nicht gesichert oder praktisch einfach
nicht vorhanden.
• Hohe Empfindlichkeit gegenüber Ausreißern
• Oft ist die Wahrscheinlichkeit für das Auftreten einer Ausprägung interessanter, als die Ausprägung selbst.
2.6.3 Logistische Regression
Um diese Nachteile zu behandeln bietet sich die logistische Regression an.
Grundlagen
Die logistische Regression behandelt nicht die Vorhersage einer numerischen,
abhängigen Variablen, sondern gibt eine Eintrittswahrscheinlichkeit eines Ereignisses an. Somit kann die abhängige Variable nur Werte zwischen 0 (“Ereignis tritt nicht ein”) und 1 (“Ereignis tritt ein”) annehmen.
Für das Data-Mining ist offensichtlich ein Ereignis wie “Testvektor gehört
zu Klasse A” interessant. Folglich braucht man hier für jede mögliche Klasse
ein Modell, wie dies bei der linearen Regression mit Mehrfachantworten der
Fall ist10 .
Grundmodell
Die logistische Regressionsgleichung für den einfachen Zwei-Variablen-Fall
lautet
eα+βxi +ui
πi =
1 + eα+βxi +ui
9
Z.B. mit dem Gauss’schen Eliminationsverfahren s. http://home.t-online.de/home/
arndt.bruenner/mathe/scripts/regr.htm
10
Beachte, dass bei der lin. Regr. m. Mehrfachantworten für jede mögliche Klasse jeweils
ein Wert zwischen 0 und 1 approximiert wird
77
Kapitel 2 Grundlagen
Noch kürzer geschrieben ergibt sich
πi =
1
1+
e−(α+βxi +ui )
.
πi ist hierbei die EintrittsWahrscheinlichkeit des Ereignisses; α, β, . . . sind
ähnlich wie bei der linearen Regression Gewichtungsparameter sog. Grundgesamtheitsparameter. ui ist der stochastische Anteil, der uns nicht weiter
interessiert.
Da hier mit Wahrscheinlichkeiten gearbeitet wird11 , gibt es folglich auch
einen Schätzer für diese Eintrittswahrscheinlichkeit. Dieser Schätzer wird
bezeichnet als π̂i = pi = P (Y = 1) im Folgenden nur noch als pi bezeichnet.
α, β, . . . sind unbekannt und müssen wie bei der linearen Regression aus den
Trainingsdaten geschätzt werden. Diese berechneten Werte werden dann als
a, b, . . . notiert und als Logit-Koeffizienten bezeichnet.
pi =
1
ea+bxi
=
a+bx
−(a+bx
i
i)
1+e
1+e
Die Schätzung der Logit-Koeffizienten erfolgt in der Praxis meist mit der
“Maximum-Likelihood-Methode”.
Es ist zu erkennen, dass bei diesem Modell der nicht-lineare Zusammenhang
zwischen der abhängigen und einer bzw. mehreren unabhängigen Variablen
im Vordergrund steht. Gerade bei Anwendungen in der Ökologie, aber auch
anderen Bereichen ist der logistische Zusammenhang interessanter oder sogar
als einziger adäquat, da sich hiermit Wachstums- und Sättigungseigenschaften besser ausdrücken lassen.
In Abb. 2.27 ist der Verlauf der Funktion für den einfachen Zwei-Variablenfall
dargestellt. Bei f (x) ist a = 0 und b = 1; bei g(x) ist a = −20 und b = 5.
Die Regressionskurve verläuft immer punktsymmetrisch zum Wendepunkt
des Graphen. Es fällt deutlich auf, dass sich extreme x-Werte kaum auf die
abhängige Variable auswirken, da der Graph asymptotisch gegen 0 bzw 1
verläuft. Dies ist eine der vorstechenden Eigenschaften der logistischen Regression, da das Modell somit robust gegenüber Ausreißern ist.
Die Rolle der Logit-Koeffizienten in einer derartigen Gleichung ist schwer
zu beschreiben aufgrund der auftretenden Wechselwirkungen zwischen den
Parametern. Der Koeffizient a hat anscheinend keinen Einfluss auf den Verlauf bzw. die Krümmung des Graphen. Er “verschiebt” die Kurve nur horizontal12 . Der Einfluss von b auf den Verlauf der Kurve ist nicht so leicht
11
Hieraus folgt auch, dass die Wahrscheinlichkeit für den Nicht-Eintritt des Ereignisses
P (Y = 0) = 1 − P (Y = 1) = 1 − pi ist
12
vgl. die Rolle von w0 bei der linearen Regression in Abschnitt 2.6.2
78
2.6 Lineare und logistische Regression - Modell und Lernverfahren
1.5
f (x) = 1+1−x
1
g(x) = 1+e−(−20+5x)
pi
1
0.5
0
−0.5
−10
−5
0
5
10
x
Abbildung 2.27: Beispiele für logistische Regression
anzugeben, was erst im Mehrvariablenfall (mit mehreren bj ) sehr deutlich
wird.
Es lässt sich allerdings schon anhand des Beispiels aussagen, dass bei hohen
b-Werten die Kurve immer steiler verläuft. Läuft |bj | gegen 0, so nimmt die
Kurve nach und nach die Gestalt einer Geraden an. Bei Werten < 0 wird die
Steigung der Kurve stets negativ.
Logit-Modell
Um den Einfluss der Logitkoeffizienten weiter zu interpretieren, bietet sich
das Logit-Modell an.
Wir ersetzen zur Vereinfachung der Umformungen in der logistischen Regressionsgleichung den Teil α + βj xij durch z. Dann erhält man sehr schnell das
79
Kapitel 2 Grundlagen
Logit-Modell:
ez
1 + ez
z
πi (1 + e ) = ez
πi + ez πi = ez
πi
= ez − ez πi
πi
= ez (1 − πi )
πi
= ez
1−πi
πi
ln 1−π
=z
i
πi
⇔
⇔
⇔
⇔
⇔
⇔
=
(2.1)
(2.2)
(2.3)
Hierbei ist
• (1) die logistische Regressionsgleichung,
• der linke Teil von (2) ist der sogenannte Odds
πi
1−πi
• und (3) ist die Link-Funktion bzw. das Logit-Modell.
Der Odds ist so interessant, weil er genau das Verhältnis von Eintritt des
Ereignisses (πi ) und Nicht-Eintritt (1 − πi ) beschreibt.
Der logarithmierte Odds bildet dann die Link-Funktion bei (3), die man auch
als Logit bezeichnet:
πi
Γ(πi ) = ln
1 − πi
Durch Einsetzen des Regressionsausdrucks z erhält man dann das binäre
πi
Logit-Modell z.B. für den Zwei-Variablen-Fall:ln 1−π
= α + βxi . Allgemeiner
i
bei k unabhängigen Variablen und mit Verwendung der geschätzten LogitKoeffizienten ergibt sich dann
k
X
pi
ln
=a+
bj xij .
1 − pi
j=1
Durch Exponentiation zur Basis e auf beiden Seiten entsteht somit:
k
k
P
P
k
Y
a+
bj xij
bj xij
pi
a
a
j=1
j=1
=e
=e e
=e
ebj xij .
1 − pi
j=1
80
2.6 Lineare und logistische Regression - Modell und Lernverfahren
Bedeutung des Effekt-Koeffizienten eb
Der sogenannte Effekt-Koeffizient ebj bietet sich an, wenn man den Einfluss
der exogenen Variablen (xij ) auf den Odds (das Wahrscheinlichkeitsverhältnis) untersuchen will. Erhöht man z.B. im zwei-Variablen-Fall diese exogene
Variable um eine Einheit, wird deutlich wie dieser Effekt-Koeffizient entsteht
und wie er die Wahrscheinlichkeiten beeinflusst:
=
=
=
=
ea+b(xi +1)
ea eb(xi +1)
ea ebxi +b
ea ebxi eb
pi
eb
1−pi
Eine Erhöhung von xi um 1 beeinflusst also den Odds linear. Es ist allerdings zu beachten, dass es sich beim Odds um das Wahrscheinlichkeitsverhältnis handelt, nicht um die Wahrscheinlichkeit des Eintretens des Ereignisses. Betrachtet man nochmal den Verlauf der e-Funktion in Abb.2.28
wird deutlich, dass ein negativer Regressionskoeffizient b das Wahrscheinlichkeitsverhältnis verringert (eb < 1), während positive Koeffizienten den
Odds erhöhen13 . Hier liegt also offenbar ein Wechselspiel zwischen Effekt8
7
6
5
eb
4
3
2
1
0
−3
−2
−1
0
1
2
b
Abbildung 2.28: Exponentialfunktion
Koeffizienten und Veränderungen der unabhängigen (exogenen) Variablen
vor. Interessant bleibt trotzdem, wie diese sich auf die Wahrscheinlichkeit
pi auswirken. Der Autor stellt dieses so wie Abb. 2.29 dar. Hier ist angege13
bemerke auch, dass für den Effekt-Koeffizient immer eb ≥ 0 gilt
81
Kapitel 2 Grundlagen
487:9)<;=>4!.?*4@4A
!"#"$%&
2..#.3"0(/4"5145146.
p
'(*)+$,-"./"0.12i .
eb
;
9
84@4A
M
N#O
D"#EGFP0.3I#514Q7
=
<1
K b K #EC#.
e
*B2.36.."#(>4"#514514.
ALI
K Y =1
Y =0
B84@4A
C
D"EGFH#.I514J7
=
>1
K b "0.3
#.
e
*2..#.3"0(/4"5145146.
ALI
K Y =1
Y =0
Abbildung 2.29: Auswirkung einer Erhöhung der exogenen Variable auf pi
ben, wie sich eine Erhöhung von exogenen Variablen in den verschiedenen
Wertebereichen von eb auswirken.
Alle hier gemachten Betrachtungen gehen davon aus, dass immer nur eine
der exogenen Variablen sich verändert, da sonst das System noch schwerer zu
analysieren ist aufgrund der auftretenden wechselseitigen Beeinflussungen.
Nachteile
Nachteile der logistischen Regressionsanalyse gibt es aber auch:
• Es sollten mindesten mehr als 100 Stichproben vorliegen
• Nur metrische Variablen können richtig erfasst werden
• Die unabhängigen Variablen müssen unkorreliert sein
• Einschränkungen der Maximum-Likelihood-Methode wie z.B. Vorhandensein beider Ausprägungen Y = 1 und auch Y = 0
82
2.6 Lineare und logistische Regression - Modell und Lernverfahren
2.6.4 Regressions- und Modellbäume
Regressions- und Modellbäume sind sehr mächtige maschinelle Lernverfahren für das Data-Mining. Sie weisen eine gewisse Ähnlichkeit mit Entscheidungsbäumen auf, haben aber andere Ansprüche und Kriterien.
Grundlagen
Regressions - und Modellbäume dienen zur Vorhersage von numerischen Werten, was der größte Unterschied zu klassischen Entscheidungsbäumen ist,
wobei Regressionsbäume in den Blättern einen Durchschnittswert der Trainingsinstanzen enthalten und Modellbäume ein zum Beispiel lineares Modell,
was den eigentlichen Wert bestimmen soll. Regressionsbäume sind deshalb
ein Spezialfall von Modellbäumen. Mit dem in Abschnitt 2.6.2 beschriebenen
Verfahren lassen sich solche Bäume sehr gut zur Klassifizierung von Testinstanzen verwenden.
Glättungsverfahren
Ein Modellbaum wird normalerweise bis zu seinem Blatt durchlaufen, wo
sich dann ein Regressionsmodell befindet, das den Wert für die Testinstanz
vorhersagt. Da es unter Umständen wie zum Beispiel wenigen vorhanden
Trainingsdaten sehr große Unterschiede zwischen zwischen benachbarten Modellen geben kann, hat sich in der Praxis die Durchführung eines Glättungsverfahren als sehr sinnvoll gezeigt.
Hierbei werden Regressionsmodelle nicht nur für die Blätter des (beschnittenen) Baumes angelegt, sondern auch für jeden einzelnen Knoten. Dadurch
kann man den vorhergesagten Wert mit Werten aus vorhergehenden Knoten
kombinieren und dadurch die Qualität eines solchen Baumes noch verbessern.
Eine Gleichung zur Glättung lautet:
p0 =
np + kq
n+k
p0 ist die an den nächsthöheren Knoten hochzureichende Vorhersage, p ist
die Vorhersage, die der aktuelle Knoten von unten bekommt, q ist der Wert
des Modells im aktuellen Knoten n die Anzahl Trainingsinstanzen und k eine
sogenannte Glättungskonstante.
83
Kapitel 2 Grundlagen
Aufbau eines Baumes
Der Aufbau eines Regressionbaumes gliedert sich in mehrere Phasen:
• Ein Induktionsalgorithmus erzeugt den anfänglichen Baum aus den
Trainingsdaten ähnlich den Entscheidungsbäumen
• Sobald der Grundbaum aufgebaut ist, wird erwogen ihn an einigen
Stellen zurückzuschneiden, falls dieses die Qualität der Ergebnisse verbessern könnte.
Induktion des Baumes
Der Aufbau des Grundbaumes nutzt wie Entscheidungsbäume ein Aufteilungskriterium anhand dessen man entscheidet, welches Attribut genutzt
wird, um die Trainingsdatenmenge T aufzuteilen.
Im Gegensatz zu Entscheidungsbäumen dient hier nicht die Informationsmaximierung als Kriterium, sondern es wird die Standardabweichung der
gesamten Trainingsdaten berechnet und als Fehlermaß festgelegt. Es wird
dann an jedem Knoten für jedes Attribut die Fehlerreduktion berechnet. Das
Attribut, dass dann diese Reduktion maximiert ist das Teilungsattribut.
Die Fehlerreduktion wird auch als Reduktion der Standardabweichung bezeichnet und mit SDR14 abgekürzt. Sie berechnet sich mit
SDR = sd(T ) −
X |Ti |
i
|T |
× sd(Ti ).
sd(T ) ist die Standardabweichung der gesamten Trainingsdaten und Ti sind
die entstehenden Teilmengen für das gewählte Attribut. Es wird nicht weiter
aufgeteilt, falls die vorhergesagten Werte der Instanzen, die einen Knoten erreichen nur leicht variieren oder anders ausgedrückt die Standardabweichung
in diesem Knoten nur ein kleinen Bruchteil der gesamten Standardabweichung ist15 . Es wird auch nicht weiter aufgeteilt, wenn an dem Knoten nur
noch eine kleine Menge der Trainingsinstanzen(zum Beispiel 4 oder weniger) vorhanden ist. In der Praxis hat sich gezeigt, dass Veränderungen dieser
Schwellwerte sich nicht extrem auf die Qualität der Ergebnisse auswirken.
14
15
Standard Deviation Reduction
Der Autor schlägt hier 5% vor
84
2.6 Lineare und logistische Regression - Modell und Lernverfahren
Beschneiden des Baumes
Das Beschneiden eines Baumes nutzt auch die bei der bereitsangesprochenen Glättungsmethode entstandenen Regressionsmodelle in jedem Knoten.
Bei diesen Modellen werden aber nur die Attribute verwendet, die vorher
noch nicht zur Entscheidungsfindung genutzt wurden. Die Anzahl der verwendeten Attribute sinkt also mit tieferen Ebenen des Baumes. Das verwendete Pruning-Verfahren benutzt die Abschätzung der erwarteten Fehlerrate
der Testdaten. Zuerst wird die (absolute) Differenz zwischen vorhergesagtem
Wert und tatsächlichem Wert für alle Trainingsinstanzen, die den Knoten
erreichen gemittelt. Weil der Baum ja nur auf den Trainingsdaten arbeitet,
wird dieser Durchschnitt den Fehler für nicht beachtete Fälle unterschätzen.
n+v
multipliziert. n ist
Daher wird dieser Durchschnitt noch mit dem Faktor n−v
die Anzahl der Trainingsdaten, und v die Anzahl der Parameter im Regressionsmodell des aktuellen Knotens.
Das Beschneidungsverfahren beginnt unten im Baum und berechnet diese
Fehlerrate für jeden Knoten und dessen Unterbaumes. Die Fehlerrate der
beiden Verzweigungen wird hierbei jedoch noch mit der Anzahl der Trainingsinstanzen in den Verzweigungen gewichtet, damit nicht geringe Mengen
von Trainingsinstanzen das Gesamtergebnis beeinflussen. Ist die Fehlerrate
im Unterbaum nun größer als im aktuellen Knoten, wird der aktuelle Knoten
zum Blatt umgewandelt, da ja eine weitere Verfolgung der Verzweigungen
für die Qualität der Vorhersagen keinen Sinn machen würde.
Nominale Attribute
Die Regression an sich ist ein numerisches Verfahren, weswegen sich natürlich
die Frage stellt, wie man mit nominalen Attributen wie zum Beispiel “kalt”,
“rot”, “beliebt” oder anderen umzugehen hat.
Die Lösung ist hier, solche Attribute in binäre Variablen zu transformieren. Man berechnet für jedes nominale Attribut der Trainingsinstanzen den
Durchschnitt der zugehörigen Klassenwerte und listet diese sortiert nach dem
Wert auf. Das nominale Attribut wird dann, wenn es k mögliche Ausprägungen hat, durch k − 1 synthetische Binärattribute ersetzt. Das i-te ist dann
0, falls der beobachtete Wert einer Instanz aus den ersten i dieser Folge
synthetischer Attribute stammt, sonst ist es 1.
85
Kapitel 2 Grundlagen
Fehlende Werte
Fehlende Werte sind in der Praxis oft eher die Regel als die Ausnahme,
weswegen man sich hier Gedanken machen sollte. Es wird die Formel zur
SDR-Berechnung abgeändert zu


X
m
|Tj |
SDR =
× sd(T ) −
× sd(Tj )
|T |
|T |
j∈{L,R}
m ist die Anzahl der Instanzen ohne das fehlende Attribut, T die Menge
Instanzen, die den Knoten erreichen und TL und TR sind die entstehenden Teilmengen durch Aufteilen an diesem Attribut. Instanzen, denen dieses
Attribut fehlt müssen jedoch auch aufgeteilt werden, deshalb gibt es das
Verfahren der Leihaufteilung16 bei dem einfach ein anderes Attribut als das
fehlende verwendet wird. Es wird das Attribut als Ersatz genommen, dass
am stärksten mit dem fehlenden korreliert. Dies ist in der Praxis jedoch nicht
verwendbar, da es mit einem erheblichen Rechenaufwand verbunden ist.
Einfacher ist es zum Beispiel den bekannten Klassenwert als Ersatz zu verwenden was aber voraussetzt, dass genau dieses Attribut mit der größten
Wahrscheinlichkeit mit dem zur Aufteilung verwendeten Attribut korreliert.
Dies funktioniert natürlich nur bei der Verarbeitung der Trainingsinstanzen,
da für Testinstanzen der Klassenwert nicht bekannt ist. Hier bietet sich am
einfachsten an, den unbekannten Attributwert mit dem Durchschnittswert
der Trainingsinstanzen für dieses Attribut zu ersetzen.
Codeskizzen
Hier sind noch ein paar Pseudomethoden formuliert, die das Erstellen eines
Modellbaumes demonstrieren sollen.
Die eigentliche Hauptmethode:
Node MakeModelTree (instances) {
SD=sd(instances); /* Standardabweichung aller
Trainingsinstanzen */
convertNominals(); //nominale Attribute umwandeln
root=newNode();
// Wurzel erzeugen
root.instances=instances; // Trainingsdaten zuweisen
split(root); // rekursiven Aufteilungsalgorithmus verwenden
16
Surrogate Splitting
86
2.6 Lineare und logistische Regression - Modell und Lernverfahren
prune(root);
return root;
}
// Baum rekursiv beschneiden
// Baum zurückgeben
Der Aufteilungsalgorithmus:
void split(node) {
if ((node.nInstances()<4)|(sd(node.instances)<0.05*SD))
node.type=LEAF; // Abbruchkriterium ? Dann Blatt
else {
node.type=INTERIOR;
berechne SDR für alle Attribute
node.attribute=Attribut mit max. SDR; /* Aufteilungsattribut
wählen */
split(node.left); // links weiter splitten
split(node.right);// rechts weiter splitten
}
}
Das Pruning:
void prune (node) {
if (node.type == INTERIOR) {
prune(node.leftChild);
// Links weiter
prune(node.rightChild); // Rechts weiter
node.model =
//Regressionsmodell erstellen
linearRegression(node);
if (subtreeError(node)>error(node))
node.type = LEAF; // Fehler im Unterbaum größer als
// Fehler im Node ?
// dann beschneiden
}
}
Fehlerabschätzung im Unterbaum mit Gewichtung der Anzahl Trainingsinstanzen in den Teilbäumen:
void subtreeError(node) {
87
Kapitel 2 Grundlagen
l=node.left;
r=node.right;
if (node == INTERIOR) {
return ( sizeof(l.instances)*subtreeError(l)
+sizeof(r.instances)*subtreeError(r))
/ sizeof(node.instances)
} else return error(node)
}
Die Funktion error(node) errechnet dabei den Fehler für ein Blatt wie folgt:
P
Instanzen|Abweichung vom vorhergesagten Klassenwert|
n+v
×
n−v
n
mit n als Anzahl Instanzen am Knoten und v Anzahl der Parameter im
Regressionsmodell.
Beispielbaum
Ein Beispiel für einen nach diesen Algorithmen erzeugten Modellbaum mit
linearer Regression ist in Abb. 2.30 dargestellt.
pgewinn
<=3.5
>4.5
[3.5,4.5]
motor
spindel
vgewinn
D,E,C
B,A
LM3
<=2.5
LM4
>2.5
LM5
D,E,C,B
LM6
A
LM7
spindel
D,E,C
LM1
B,A
LM2
Abbildung 2.30: Beispiel für einen Modellbaum
Es soll die Beschleunigungszeit eines Servosystems vorhergesagt werden, wobei ein Servoverstärker, ein Motor, eine Leitspindel und ein Gleitwagen teil
des Systems sind.
88
2.6 Lineare und logistische Regression - Modell und Lernverfahren
Die zugehörigen linearen Modelle sind in Tabelle 2.2 angegeben.
Modell
Konstante
pgewinn
vgewinn
motor=D
motor=D,E
motor=D,E,C
motor=D,E,C,B
spindel=D
spindel=D,E
spindel=D,E,C
spindel=D,E,C,B
LM1
−0.44
LM2
2.60
0.82
vs.
vs.
vs.
vs.
vs.
vs.
vs.
vs.
E,C,B,A
C,B,A
B,A
A
E,C,B,A
C,B,A
B,A
A
LM3
3.50
LM4
0.18
LM5
0.52
0.24
−0.16
0.10
0.42
LM6
0.36
0.42
3.30
1.80
LM7
0.23
0.06
0.15
0.09
0.22
0.07
0.18
0.47
0.63
0.28
0.90
0.34
0.16
0.14
Tabelle 2.2: Lineare Modelle für Beispielbaum
In diesem Beispiel werden 2 nominale und 2 numerische Attribute verwendet.
Die nominalen wurden nach dem Verfahren in Abschnitt 2.6.4 in entsprechende synthetische binäre Attribute umgewandelt. Die Dreifachabzweigung bei
pgewinn ist Resultat eines Algorithmus17 , der bestimmte gleiche Teile eines
Baumes zusammenfasst.
Somit ist das LM2 z.B. 2.60 + 3.30 ∗ 1, falls Motor=D ist. In diesem Modell wirken sich also andere Ausprägungen des Motors überhaupt nicht aus.
Bei LM1 wiederum ist ein Motor vom Typ D oder E ausschlaggebend. Bei
LM7 würde sich die Ausprägung Motor=D bzw Motor=E mehrfach auf den
vorhergesagten Wert auswirken, während Motor=C nur einmal einfließt.
2.6.5 Schlusswort
Regressionsbäume wurden 1984 mit dem CART-System18 von Breiman et al.
zum ersten Mal implementiert. Neben einem Entscheidungsbauminduzierer
enthielt es ein System zur Regressionsbaumerstellung. Inzwischen hat es sich
weiterentwickelt und beinhaltet Methoden um zum Beispiel mit fehlenden
Werten umzugehen, nominale Attribute zu verarbeiten und vieles mehr.
Diese Formen des Data-Mining finden vermehrt in Domänen wie zum Beispiel
CRM-Analysen, Profilerstellung und anderen Anwendungen. Die wachsende
Nachfrage hat über die Jahre natürlich dafür gesorgt, dass auch der Markt
für diese Art von Software immer größer wurde.
Verfahren zur Modellbauminduktion sind noch relativ jung und müssen sich
wohl erst in der Praxis bewähren. Modellbäume sind flexibel, so ist aus ihnen
17
laut Autoren ist dieser Algorithmus sehr einfach und schaut, ob die Wurzel und einer
ihrer Nachfahren das gleiche Attribut auswerten
18
C lassification And RegressionT rees http://www.salford-systems.com/
89
Kapitel 2 Grundlagen
zum Beispiel auch das Verfahren der lokal gewichteten Regression entstanden, in dem die einzelnen Modelle sich noch gegenseitig beeinflussen also
zur Laufzeit gefunden werden. Außerdem ist man nicht auf lineare Modelle
beschränkt und kann vielfältige andere Gewichtungsfunktionen oder Pruningalgorithmen verwenden.
90
2.7 Clustering
2.7 Clustering von Hauke Tschirner
2.7.1 Einleitung
Ziel dieser Ausarbeitung ist es, durch die Vorstellung einiger Prinzipien, eine
Einführung in den Bereich des Clustering zu geben.
2.7.2 Der Begriff Clustering
Zuerst soll an dieser Stelle eine grundlegende Vorstellung darüber geschaffen
werden, was der Begriff Clustering umfasst. Grundsätzlich wird Clustering in
der Literatur als Verfahren beschrieben, welches gleichartige Daten zu sogenannten Clustern zusammenfasst. Gleichartigkeiten zwischen Daten werden
dabei zumeist durch Abstände zwischen einzelnen Datenobjekten gemessen.
Ein Vorteil von dieser Kategorisierung ist etwa eine Zeitersparniss, da man
gleichartige Daten auf ähnliche bzw. gleiche Weise behandeln kann. Zusätzlich fördert Clustering eine Fokussierung auf Daten mit bestimmten Merkmalen.
2.7.3 Datentypen in der Cluster-Analsye
Typischerweise operieren main-memory-basierte Clusteringverfahren auf den
folgenden zwei Datentypen
Data matrix
In dieser Matrix sind die Datenobjekte und ihre Attributwerte gesichert. In
vertikaler Ebene werden die n Datenobjekte unterschieden. Dies könnten z.B.
Personen sein. In horizontaler Ebene sind die Attributwerte der einzelnen
Datenobjekte gesichert, also z.B. Name, Geburtsdatum, usw. .
91
Kapitel 2 Grundlagen
Dissimilarity matrix
In dieser Matrix werden die Abstände der Datenobjekte untereinander gesichert. Hierbei bezeichnet etwa d(2,1) den Abtand zwischen Datenobjekt 2
und Datenobjekt 1.
2.7.4 Berechnung der Abstände
Abstände zwischen Datenobjekten sind bei vielen Clusteringverfahren ein
wesentlicher Faktor zur Einordnung dieser Daten. Die Art der Berechnung
der Abstände hängt dabei von der Art der verglichenen Attribute ab. Grundsätzlich kann man zwei wesentliche Ausprägungen der Abstandsberechnung unterscheiden:
Die euklidische-, Manhattan- (oder cityblock-) und Minkowski-Distanz wird
bei Vergleich von linearen Zahlenwerten, etwa Höhe, Gewicht, usw., angewendet, kann aber auch, nach logarithmischer Transformation, bei exponentiellen Werten, etwa exponentiellen Wachstumswerten, angewendet werden.
p
Euklidische Distanz d(i, j) = |xi1 − xj1 |2 + |xi2 − xj2 |2 + ... + |xip − xjp |2
Manhattan-Distanz d(i, j) = |xi1 − xj1 | + |xi2 − xj2 | + ... + |xip − xjp |
1
Minkowski-Distanz d(i, j) = (|xi1 − xj1 |n + |xi2 − xj2 |n + ... + |xip − xjp |n ) n
Zur Berechnung dieser Distanzen werden die einzelnen Attribute der Datenobjekte verglichen, d.h. jeweils subtrahiert, und diese Differenzen werden addiert. Dabei ist die Minkowski-Distanz eine Verallgemeinerung der
euklidischen- und der Manhattan-Distanz, wobei n=2 im Falle der euklidischen Distanz und n=1 im Falle der Manhattan-Distanz.
Bei binären Attributwerten findet ein Vergleich mit Hilfe des simple-matchingund des Jaccard-Koeffizienten statt.
simple-matching-Koeffizient d(i, j) =
r+s
Jaccard-Koeffizient d(i, j) = q+r+s
92
r+s
q+r+s+t
2.7 Clustering
Dabei bezeichnet r den Fall, dass das eine Datenobjekt den Wert 1 hat und
das Andere den Wert 0. s bezeichnet den umgekehrten Fall, dass das eine Datenobjekt den Wert 0 hat und das Andere den Wert 1. q bezeichnet den Fall,
dass beide Datenobjekte den Wert 1 haben, und t bezeichnet schließlich den
Fall das Beide den Wert 0 haben. Welcher Koeffizient zur Berechnung genutzt
werden muss hängt von der Bedeutung der binären Attributwerte ab. Ist es
ohne Bedeutung ob ein Attribut den Wert 0 oder 1 zugeordnet bekommt,
also etwa in einer reinen Unterscheidung wie männlich − weiblich, so nennt
man dies invariante Ähnlichkeit. In diesem Fall nutzt man zur Berechnung
des Abstandes den simple-matching-Koeffizienten. Ein weiterer Fall ist, dass
die Vergabe des Attributwertes 0 oder 1 eine Bedeutung hat, also etwa bei
Zuständen wie positiv und negativ bei Feststellung medizinischer Befunde,
wobei das seltenere Ergebnis, etwa HIV-positiv, mit 1 codiert wird und das
häufigere Ergebnis, etwa HIV-negativ, mit 0. Hierbei spricht man von nichtinvarianter Ähnlichkeit. In diesem Fall nutzt man den Jaccard-Koeffizienten
zur Berechnung de Abstandes.
Bei nominalen Attributwerten, d.h. bei Werten mit mehreren Zuständen,
z.B. Farbe: blau, rot, gelb, grün, nutzt man eine abgewandelte Form des
simple-matching-Koeffizienten.
2.7.5 Kategorien von Clusteringverfahren
Clusteringverfahren können grob in fünf Kategorien eingeteilt werden, welche
im Folgenden kurz vorgestellt werden.
Partitionierungsverfahren
Bei diesen Clusteringverfahren legt man die Zahl k der gewünschten Cluster
zu Beginn fest. Initial werden dann k Clustermittelpunkte willkürlich festgelegt. Dies könnten z.B. Datenobjekte selbst sein. Um nun festlegen zu können
welche Datenobjekte welchem Cluster zuzuordnen sind, wird für jedes Datenobjekte festgestellt in welchem Abstand es sich zu den Clustermittelpunkten
befindet. Es wird dann demjenigen Cluster zugeordnet, von dessen Mittelpunkt es den geringsten Abtand hat.
Ein wesentlicher Nachteil bei diesem simplen Verfahren ist deutlich: Die
erzeugten Cluster sind vollständig von der initialen Festlegung der Clustermittelpunkte abhängig. Daher existieren Algorithmen die eine iterative
Verbesserung der Clusterbildung vollziehen. Die Algorithmen k-means und
k-medoids werden an späterer Stelle noch einmal genauer betrachtet.
93
Kapitel 2 Grundlagen
Hierarchische Verfahren
Bei diesen Verfahren werden die Cluster hierarchisch erzeugt. Man unterscheidet dabei zwei Richtungen: agglomerativ und divisiv. Agglomerative
Verfahren bezeichnen dabei ein bottom-up-Vorgehen bei der Clustererzeugung. D.h. zu Beginn eines agglomerativen Algorithmus bilden alle Datenobjekte jeweils ein eigenes Cluster und werden dann schrittweise zu größeren
Clustern zusammengefasst. Divisive Verfahren bezeichnen hingegen ein topdown-Vorgehen. Bei divisiven Algorithmen bilden also zu Beginn alle Datenobjekte ein Cluster und werden schrittweise in kleinere Cluster aufgesplittet.
Ein Nachteil bei hierarchischen Verfahren dieser simplen Vorstellung ist, dass
einmal gemachte Schritte nicht mehr rückgängig zu machen sind. Daher wurden Algorithmen entwickelt, die etwa eine Relokation von Datenobjekten
erlauben (BIRCH) oder genauere Analysen der Objektverbindungen vollziehen (CURE), um eine verbesserte Clusterbildung zu erreichen. Auf einige
hierarchische Algorithmen wird im weiteren Verlauf noch eingegangen.
Dichte-basierte Verfahren
Diese Verfahren unterscheiden sich deutlich von den bisher vorgestellten Methoden durch die Form in der die Cluster entstehen. Bei dichte-basierten
Methoden wächst ein Cluster schrittweise, bis ein gewisser Grenzwert an
Objektdichte erreicht wird. Die Objektdichte, d.h. also die Zahl der Datenobjekte in der Umgebung eines anderen Datenobjektes, wird anhand eines
festgelegten Radius um ein Datenobjekt gemessen. Dieser Radius wird im
Folgenden als neighborhood bezeichnet.
Dadurch dass Cluster bei diesen Verfahren schrittweise wachsen, erkennen
dichte-basierte Algorithmen Cluster von willkürlicher Form. Bei den zuvor
vorgestellten Verfahren ist dies nicht ohne weiteres möglich. Der Algorithmus
DBSCAN wird im weiteren Verlauf näher vorgestellt.
Gitter-basierte Verfahren
Bei diesen Verfahren wird das gesamte Objektfeld in Gitterzellen aufgeteilt.
Diese Gitterzellen können weiterhin Sub-Gitterzellen enthalten, so dass eine
Art hierarchischer Gitterstruktur entsteht. Gitter höherer Ordnung enthalten dabei Informationen über den Inhalt ihrer Sub-Gitter. Die Gitterzellen
bilden dabei die Cluster auf dem Datenfeld.
Interessant ist bei diesen Verfahren, dass, nach Erzeugung der Gitterzellen, Anfragen auf die Daten in den Clustern sehr schnell behandelt werden
94
2.7 Clustering
können. Ein Nachteil ist natürlich eine fehlende Genauigkeit der entstandenen Cluster.
An dieser Stelle seien nur zwei Algorithmen genannt: STING und CLIQUE.
Genauere Informationen über diese Verfahren sind in der Literatur vorhanden.
Modell-basierte Verfahren
Bei diesen Verfahren wird ein gewünschtes Modell des vervollständigten Clusterings als Hypothesenmodell aufgestellt. In weiteren Schritten dieser Verfahren wird versucht ein best-fit für die gegebene Datenmenge auf das Hypothesenmodell zu finden. Da diese Verfahren im folgenden nicht weiter behandelt
werden, sei an dieser Stelle wiederum auf die Literatur hingewiesen.
2.7.6 Algorithmen der Partitionierungsverfahren
k-means
Der Algorithmus k-means strukturiert Cluster, indem er Mittelpunkte (means)
der Cluster ermittelt und Datenobjekte entsprechend der Entfernung zu diesen Mittelpunkten den jeweiligen Clustern zuordnet. D.h. jedes Datenobjekt
wird demjenigen Cluster zugeordnet, dessen Mittelpunkt es am nahesten
liegt. In einer Schleife wird dann jeweils ein neuer Mittelpunkt als Mittelwert aller Datenobjekte eines jeweiligen Clusters ermittelt und eine neue
Clusteranalyse gestartet. Es folgt nun der k-means Algorithmus, wobei k die
Anzahl der zu erzeugenden Cluster einer Datenbank von n Objekten bezeichnet:
(1) arbitrarily choose k objects as the initial cluster centers;
(2) repeat
(3) (re)assign each object to the cluster to which the object is most similar,
based on the value of the objects in the cluster;
(4) update the cluster means, i.e. calculate the mean value of the objects for
each cluster;
(5) until no change;
Die Arbeitsweise des Algorithmus wird durch folgendes Beispiel klar.
Hierbei wird angenommen, dass drei Cluster zu erwarten sind, also k=3. Die
Punkte bezeichnen die Datenobjekte. Ein Plus steht für einen Clustermittelpunkt, und die gestrichelten Linien begrenzen die einzelnen Cluster.
95
Kapitel 2 Grundlagen
Abbildung 2.31: Ein Beispiel für die Anwendung von k-means aus [Han01],
S.350
In Schritt (a) wurden bereits die ersten Cluster, anhand der Entfernungen
der Datenobjekte zu den Clustermittelpunkten, ermittelt. Die Mittelpunkte wurden aber noch nicht angepasst. Dies ist in Schritt (b) geschehen. Die
Clustermittelpunkte wurden entsprechend der Datenobjekte in den Clustern
verschoben und ein neuer Abgleich der Entfernungen der Datenobjekte zu
den neuen Mittelpunkten ergab veränderte Clusterzugehörigkeiten. In Schritt
(c) sieht man die entgültigen Cluster durch fette Linien getrennt. Hier gab es
keine Veränderungen der Clusterzuordnung nach Durchlaufen einer Schleife.
Die Komplexität dieses Algorithmus ist O(nkt), wobei t die Zahl der Iterationsschritte bezeichnet. n und k wurden zuvor bereits definiert.
Der k-means Algorithmus hat allerdings einige wesentliche Nachteile. Cluster
nichtkonvexer Form werden nur sehr schlecht erkannt. Zusätzlich muss k, also die Anzahl der zu erreichenden Cluster, zu Beginn bereits spezifiziert sein,
was insbesondere bei umfangreicheren Datenbanken ein Problem darstellt.
Auf sogenannte outliers, also Stördaten die extrem aus der Menge von Daten herausstechen und dadurch Ergebnisse verfälschen, reagiert der k-means
Algorithmus zudem sehr empfindlich. Dieser dritte Nachteil kann allerdings
durch Einsatz des k-medoids Algorithmus gemindert werden.
k-medoids
Ein medoid bezeichnet das zentralste Datenobjekt eines jeden Clusters. Bei
diesem Algorithmus wird daher nicht schrittweise der Mittelpunkt innerhalb
des Clusters verschoben, sondern springt sozusagen von einem zuvor zentralen Datenobjekt zu einem nach einem Iterationsschritt neuen zentralsten
Datenobjekt. Diese Schritte werden in folgender Graphik deutlicher.
96
2.7 Clustering
Abbildung 2.32: Ein Beispiel für die Anwendung von k-medoids aus [Han01],
S.352
Orandom bezeichnet dabei das neue zentralste Objekt eines Clusters. Oj ist
der alte Mittelpunkt dieses Clusters, Oi der Mittelpunkt eines anderen Clusters. p bezeichnet dasjenige Datenobjekt, für welches überprüft werden soll
ob es seine Clusterzugehörigkeit nun ändert. Die fette Linie bezeichnet die
bisherige Clusterzugehörigkeit, die gestrichelte Linie bezeichnet die neue Zugehörigkeit.
In Fall 1 wechselt p die Clusterzugehörigkeit, da nach Mittelpunktswechsel
Oi nun näher ist als Orandom .
In Fall 2 bleibt p Teil des bisherigen Clusters, da es Orandom näher ist als Oi .
In Fall 3 ändert sich die Clusterzugehörigkeit von p nicht, da es immer noch
Oi am nahesten ist.
In Fall 4 ändert sich die Clusterzugehörigkeit von p, da es nun Orandom am
nahesten ist.
Outliers haben hierbei wesentlich weniger Einfluss auf die Clusterbildung als
im Falle von k-means.
Typische k-medoids Algorithmen sind etwa PAM (Partitioning around medoids), bei welchem in jedem Schritt überprüft wird, ob ein anderes Datenobjekt einen besseren meidoid abgeben würde. Dieser Algorithmus arbeitet
allerdings nur auf kleinen Datenmengen effektiv. Daher wurde zum Einsatz
bei großen Datenmengen der k-medoids Algorithmus CLARA (Clustering
LARge Applications) entwickelt. CLARA wählt aus der gesamten Datenmenge nur einen Teil als Repräsentationsmenge. Durch Einsatz von PAM
werden daraufhin medoids ermittelt. CLARA wählt dabei mehrere feste Teile der Gesamtdatenmenge und liefert, nach Anwendung von PAM, das beste
Ergebnis des Clusterings zurück. Die Komplexität von CLARA ist dabei
O(ks2 + (k(n − k)), wobei s die Größe des samples, also des Datenausschnitts, bezeichnet. CLARANS (Clustering LARge Applications based upon
RANdomized Search) ist eine effektivere Variante von CLARA, bei der eine
97
Kapitel 2 Grundlagen
zufällige Auswahl von Datensamples für ein besseres Ergebnis sorgt. Obwohl
k-medoids robuster ist als k-means, ist der Einsatz doch aufwendiger.
2.7.7 Algorithmen hierarchischer Verfahren
Die folgende Abbildung zeigt die zwei grundsätzlich unterschiedlichen Ansätze
bei Algorithmen hierarchischer Verfahren.
Abbildung 2.33: Übersicht der hierarchischen Verfahren aus [Han01], S.355
Die agglomerative (bottom-up) Vorgehensweise im simplen agglomerativen
Algorithmus AGNES und die divisive (top-down) Vorgehensweise im simplen
DIANA Algorithmus.
Ein agglomerativer Algorithmus anhand eines konkreten Beispieles
In diesem Beispiel geht es um das Abfallaufkommen im Regierungsbezirk
Chemnitz des Jahres 1993. Hier ein kurzer Überblick über die vorhandenen
Daten.
Zu Beginn des Algorithmus bilden alle Kreise jeweils ein eigenes Cluster.
In jedem Schritt werden nun die zwei ähnlichsten Cluster zu einem Cluster verschmolzen. Zur Berechnung des neuen Abstandes zu den bestehenden
Clustern wird der Average Linkage Algorithmus hinzugezogen.
d(Cu , Ct ) = 12 (d(Cr , Ct ) + d(Cs , Ct ))
Wobei Cr und Cs die verschmolzenen Cluster sind. Der Abstand zum bestehenden Cluster Ct wird mittels der quadrierten euklidischen Distanz ermittelt.
98
2.7 Clustering
Abbildung 2.34: Beispieldaten zur Erzeugung des Dendogrammes aus
[Sto97], S.131
Zur graphischen Darstellung der sich ergebenden Clusterhierarchie existieren
sogenannte Dendogramme. Das dargestellte Dendogramm entstand durch
Anwendung des Average Linkage Algorithmus auf die obige Datenmenge.
99
Kapitel 2 Grundlagen
Abbildung 2.35: Dendogramm aus [Sto97], S.132
Durch einen festgelegten Grenzwert eines Clusterabstandes können nun drei
größere Cluster erkannt werden. Diese Cluster sind in der Graphik durch
Kästen markiert. Die drei letzten Kreise fallen aus dem Rahmen und können
keinem Cluster zugeordnet werden.
Beispiel eines divisiven Clustering mit Verschmelzungs- und
Aufteilungsoperationen
In diesem Beispiel werden Dateninstanzen inkrementell zu einem Baum zusammengefügt. Jede Instanz die hinzugefügt wird, wird probeweise jedem
vorhandenen Blatt als Sohn zugeordnet. Die sogenannte Kategoriennützlichkeit gibt dabei die Qualität dieser Position für die entsprechende Instanz an.
Sie gibt Auskunft über die Gesamtqualität der Aufteilung in Cluster.
Die Formel der Kategoriennützlichkeit
lautet folgendermaßen:
P
P P
2
2
l P r[Cl ]
i
j (P r[ai =vij |Cl ] −P r[ai =vij ] )
CU (C1 , C2 , ..., Ck ) =
k
vij bezeichnet dabei Werte von Attributen ai . In der innersten Schleife werden also die Werte und in einer mittleren Schleife die Attribute durchlaufen.
100
2.7 Clustering
Cl bezeichnet die Cluster. Diese werden in der äusseren Schleife durchlaufen.
P r[ai = vij |Cl ]2 bezeichnet die Wahrscheinlichkeit, dass das Attribut ai den
Wert vij im Cluster Cl annimmt, und P r[ai = vij ]2 bezeichnet die Wahrscheinlichkeit, dass das Attribut ai den Wert vij überhaupt annimmt. Der
Vergleich dieser Wahrscheinlichkeiten gibt damit die Nützlichkeit der Existenz entsprechender Cluster an, d.h. also die Nützlichkeit der Aufteilung
der Daten in Cluster. Dies geschieht durch den Vergleich von Existenz und
Nicht-Existenz. Die Division durch k sorgt für eine pro-Cluster-Angabe der
Kategoriennützlichkeit.
Zusätzlich gibt es Aufteilungs- und Verschmelzungsoperationen. Es werden
etwa zwei bereits zugeordnete Knoten verschmolzen, wenn ein neuer Knoten, durch die Kategoriennützlichkeit, sich ähnlich gut in einem Cluster mit
Beiden befinden sollte.
Die folgende Graphik zeigt den Aufbau eines solchen Baumes.
Die ersten fünf Instanzen werden als Blätter an den Knoten angefügt. Ab der
sechsten Instanz wird der Algorithmus gestartet. In Schritt (c) wurde also
Knoten f hinzugefügt, da die Kategoriennützlichkeit ergab, dass sich Knoten
f in einem Cluster mit Knoten e befinden sollte. In Schritt (e) ergab die
Überprüfung der Kategoriennützlichkeit für alle Blattknoten, dass Knoten
h einen Cluster mit Knoten a aber auch mit Knoten d bilden sollte. Daher
wird der Baum umstrukturiert, d.h. Knoten a und d werden verschmolzen
und bilden mit Knoten h einen Cluster. Schritt (f) zeigt einen finalen Baum,
in dem die hierarchische Struktur deutlich zu erkennen ist.
CURE
Der divisive Algorithmus CURE unterscheidet sich von anderen Algorithmen dahingehend, dass mehrere Repräsentationspunkte die Form eines Clusters definieren. In jedem Schleifendurchlauf des Algorithmus werden die zwei
Cluster mit den nahesten Repräentationspunkten verschmolzen und diese
Repräentationspunkte schrumpfen entgegen dem neuen Mittelpunkt der verschmolzenen Cluster. In der folgenden Graphik ist ein solcher Ablauf dargestellt.
In Schritt (b) wurden zufällig Repräsentationspunkte gewählt. Welche Datenobjekte zu den entsprechenden Clustern gehören, wird durch den Abstand zu den Repräsentationspunkten ermittelt. In Schritt (c) sieht man den
bereits weit fortgeschrittenen Algorithmus. Die Repräsentationspunkte sind
entsprechend der neuen Mittelpunkte verschmolzener Cluster zusammengeschrumpft. Zwei größere Cluster zeichnen sich ab.
101
Kapitel 2 Grundlagen
Abbildung 2.36: Beispiel eines divisiven Clustering aus [Wit01], S.232
CURE bietet die Möglichkeit outliers auszuschliessen. Die Komplexität von
CURE ist O(n). Allerdings können Kategorien-Daten nicht mit CURE bearbeitet werden. Um diese Daten zu clustern existiert ein separater Algorithmus namens ROCK.
102
2.7 Clustering
Abbildung 2.37: Ein Beispiel für die Anwendung von CURE aus [Han01],
S.360
2.7.8 Algorithmen Dichte-basierter Verfahren
DBSCAN
Der DBSCAN Algorithmus betrachtet den sogenannten neighborhood, also
den Radius um ein Datenobjekt, und prüft die Anzahl der Datenobjekte in
diesem. Erreicht diese einen Grenzwert MinPts so bildet das Datenobjekt,
dessen neighborhood geprüft wurde, ein core object. Von Datenobjekten, die
sich im neighborhood eines core objects befinden wird wiederum der neighborhood überprüft, usw. . Datenobjekte sind density-connected wenn eine
Verbindung, über den neighborhood, dieser mit einem core object möglich
ist. Solch verbundene Datenobjekte bilden die Cluster. Alle Datenobjekte die
nach Durchlauf des Algorithmus keinem Cluster zugeordnet werden konnten
sind Stördaten. Der Ablauf wird in dem folgenden Beispiel deutlich.
Angenommen MinPts=3. M, P, S und O wären core objects. Q ist etwa
density-connected mit M und P bildet mit diesen daher ein Cluster. Es
ist zu beachten das sich der Algorithmus in diesem Beispiel noch in einem
103
Kapitel 2 Grundlagen
Abbildung 2.38: Ein Beispiel für die Anwendung von DBSCAN aus [Han01],
S.364
frühen Stadium befindet. Weitere Datenobjekte, wie etwa die Unbenannten
im neighborhood von M müssten ihren neighborhood prüfen. Auf diese Weise
wächst ein Cluster an und kann so auch willkürliche Form haben.
Die Komplexität von DBSCAN ist im worst-case O(n2 ). Ein Nachteil ist, dass
für den Einsatz von DBSCAN der neighborhood und MinPts festgelegt sein
müssen. Da das gesamte Ergebnis des Clusterings sehr sensibel gegenüber
dem neighborhood ist, kann ein unzureichender Wert das Ergebnis erheblich
verfälschen. Daher wurde der Algorithmus OPTICS entwickelt, welcher eine
Hierarchie von Clustern anhand verschiedener Werte für den neighborhood
aufstellt.
104
2.8 Fallbasiertes Schliessen
2.8 Fallbasiertes Schliessen von Rainer Hilbrands
2.8.1 Einleitung
Diese Ausarbeitung beschäftigt sich mit dem fallbasierten Schließen. Zunächst
werden einige grundlegende Definitionen gegeben. Anhand einiger Beispiele soll verdeutlicht werden, was fallbasiertes Schließen ist. Danach wird auf
die Fallrepräsentation eingegangen, die Grundlage für die formale Umsetzung ist. Ein ganz zentrales Thema ist die Ähnlichkeitsbestimmung, die den
Kern des fallbasierten Schließens bildet. Desweiteren soll die Klassifikation
von Objekten erläutert werden, welches zu den analytischen Aufgaben eines
fallbasierten Systems gehört. Zu guter letzt werden die Vor- und Nachteile
dieser Methode beleuchtet.
2.8.2 Grundlagen
Was ist ”Fallbasiertes Schließen”?
Fallbasiertes Schließen löst neue Probleme durch Vergleich des Problems mit
bereits gelösten ähnlichen Problemen. Grundlage dafür ist eine sogenannte
Fallbasis, in der Probleme bzw. Erfahrungen ggf. mit Lösungen gespeichert
sind. Die Darstellung eines Falles in der Fallbasis ist Aufgabe der Fallrepräsentation, die individuell auf das jeweilige System abgestimmt werden
muß. Durch eine Ähnlichkeitsbestimmung, auf die später eingegangen wird,
werden ähnliche Probleme herausgesucht. Die Lösung des in der Fallbasis
vorhandenen Problems wird dann in modifizierter Form übernommen. Dies
geschieht, weil in den seltesten Fällen identische Problemstellungen vorhanden sind. Der neue Fall wird anschließend in die Fallbasis aufgenommen.
Beispiele für ”Fallbasiertes Schließen”
Ein Patient konsultiert seinen Hausarzt. Er schildert ihm verschiedene Symptome (z.B. Magenschmerzen, kurzfristige Schwindelgefühle). In diesem Fall
ist dies die Problembeschreibung. Danach erinnert sich der Arzt an einen
anderen Patienten, der über ähnliche Beschwerden klagte. Dieser Vorgang
beschreibt die Suche in der Fallbasis mit Ähnlichkeitsbestimmung. Nun stellt
er aufgrund dieser Erfahrung eine Diagnose und verschreibt ihm das gleiche
Medikament, allerdings in einer anderen Dosierung. Der Arzt übernimmt also
die Lösung der zuvor gemachten Erfahrung und gleicht diese dem individuellen Fall an.
105
Kapitel 2 Grundlagen
Ein Automechaniker soll den Wagen eines Kunden reparieren. Er erhält eine
kurze Beschreibung, wie sich der Fehler auswirkt. Aus Erfahrung weiß er,
dass gerade dieses Modell der Automarke XY häufig ein Problem mit einem
bestimmten Bauteil hat. Auch er hat unbewußt eine Ähnlichkeitsbestimmung
vorgenommen und wendet nun die Lösung des ihm bekannten Problems auf
das aktuell vorhandene an.
106
2.8 Fallbasiertes Schliessen
2.8.3 Fallrepräsentation
Allgemeines
Wichtiger Bestandteil des fallbasierten Schließens ist die Repräsentation der
einzelnen Fälle in der Fallbasis. Die dazu benötigten Datenstrukturen sind
stark von den jeweiligen Daten und der späteren Ähnlichkeitsbestimmung
abhängig. Es gibt keine universelle formale Umsetzung der Fallrepräsentation. Desweiteren können verschiedene Datenstrukturen miteinander kombiniert werden. Was in einem Fall gespeichert ist, hängt auch von dem jeweiligen System ab.
Im Allgemeinen enthält ein Fall eine Problembeschreibung bzw. Situationsbeschreibung. Es wird also festgehalten und welchen Bedingungen es zu
einem Fehler gekommen ist und wie sich dieser darstellt. Zudem werden
die Lösungsinformationen beschrieben. Dabei sollte auch angegeben werden,
warum diese Lösung gewählt worden ist (Begründung). Eventuell sollten
auch alternative Lösungsansätze oder Lösungswege angeboten werden. Optional wären ggf. auch Güteinformationen nützlich, wie z.B. Zeit, Kosten,
Risiko oder Akzeptanz der Lösung.
Für die formale Umsetzung der Fälle benötigt man geeignete Datenstrukturen. Hier sollen, ohne Anspruch auf Vollständigkeit, vier solcher Umsetzungen beschrieben werden:
• Attribut-Wert-Repräsentaion
• Objektorientierte Repräsentation
• Graphen
• Prädikatenlogische Repräsentation
Attribut-Wert-Repräsentation
Diese relativ einfache Form der Darstellung beschränkt sich auf die Speicherung der unterschiedlichen Merkmale mit den dazugehörigen Werten. Dies
soll anhand eines Beispiels verdeutlicht werden:
Bei einer Platine, die Teil einer Steuerungseinheit ist, liegt ein Defekt vor:
• Problem:
• Spannung an Ausgang: 14,5 V
107
Kapitel 2 Grundlagen
• Relais 1-7: [on,off,on,on,off,off,on]
• LED 23: on
• Lösung:
• Defektes Bauteil: IC-568
• Reparaturdokumentation: Handbuch D, Seite 87
Die Attribut-Wert-Repräsentation hat eine einfache Datenstruktur. Dadurch
wird auch die Ähnlichkeitsbestimmung relativ einfach. Ein Nachteil dieser formalen Umsetzung ist allerdings, dass Aktionsfolgen nicht dargestellt
werden können. Das bedeutet, dass zum Beispiel eine Beschreibung eines
Lösungsweges in nicht ohne weiteres zu repräsentieren ist. Desweiteren fehlen relationale Beziehungen zwischen einzelnen Attributen bzw. Attributgruppen. Die struktuelle Gliederung wird hier vernachlässigt. Deswegen eignet sich die Attribut-Wert-Repräsentation lediglich für einfach Systeme mit
kleinen Fallbasen, dessen Merkmale wenige Beziehungen untereinander aufweisen. Dies schränkt die Anwendbarkeit für die meisten Systeme stark ein.
Man bedient sich daher einer erweiterten Form der Attribut-Wert-Repräsentation: die Rede ist von der objektorientierten Repräsentation.
Objektorientierte Repräsentation
Die objektorientierte Repräsentation von Fällen ist eine Erweiterung der
Attribut-Wert-Repräsentation. Hier werden mehrere Attribute zu Objekten zusammengefaßt. Mehrere Objekte stehen untereinander in Beziehungen. Diese Modellierung ist bei Entwicklern sehr beliebt, da die reale Welt
dadurch leicht umzusetzen ist. Die Beziehungen spielen dabei eine wichtige
Rolle. Zwei Objekte können beispielweise in einer kompositionellen Relation stehen (”is-part-of”-Relation). Dabei setzt sich ein Objekt aus mehreren
Teilobjekten zusammen. Z.B. ist der Motor, die Reifen und das Chassis sind
Teilobjekte des Objektes Formel-1-Wagen.
In diesem Beispiel ist die Objektklasse ”Computer” eine Oberklasse der
Klasse ”Laufwerke”. Beide Klassen enthalten mehrere Attribute mit Werten.
Auch hier soll eine kleine Bewertung dieser Repräsentationsform vorgenommen werden. Anders als bei der Attribut-Wert-Repräsentation ist hier eine
strukturierte Darstellung von Fällen möglich. Ein wesentlicher Vorteil ist die
einfache Modellierung der ”realen Welt” für die Entwickler. Doch die einfache Umsetzung der Repräsentation hat seinen Preis: die spätere Entwicklung der Ähnlichkeitsbestimmung ist aufwendiger und benötigt besonders in
108
2.8 Fallbasiertes Schliessen
Abbildung 2.39: Beispiel für eine objektorientierte Repräsentation
der späteren Anwendung eine gute Performance des Rechensystems. Außerdem ist auch hier die Repräsentation von Aktionsfolgen nicht ohne weiteres
möglich. Geeignet ist die OO-Repräsentation für komplexe Fallstrukturen im
analytischen Bereich.
Repräsentation durch Graphen
Mit Hilfe von Graphen können ebenfalls Probleme gut beschrieben werden.
So kann man sich eine Repräsentation mit UML vorstellen, die Problemfälle
in der Programmierung darstellt. Im Bereich der Chemie eignen sich Graphen zur Darstellung von Molekülstrukturen. Die eigentlichen Stärken liegen jedoch im Bereich der Lösungsbeschreibung. Die Knoten des Graphen
beschreiben die auszuführenden Tätigkeiten. Die Kanten können die Reihenfolge und repräsentieren Alternativen definieren.
Bei dieser Datenstruktur sind Aktionsfolgen einfach darstellbar. Jedoch sind
die Möglichkeiten der strukturellen Gliederung stark beschränkt. Zur späteren Ähnlichkeitsbestimmung existieren gute Algorithmen aus der Graphentheorie. Es handelt sich hierbei um Tests auf Graphenisomorphie, auf die
später noch eingegangen werden soll. Diese Algorithmen sind jedoch sehr
aufwändig. So ist bespielsweise der Subgraphenisomorphie-Test NP-vollständig.
Im Allgemeinen ist diese Form der Repräsentation gut geeignet für analytische und synthetische Aufgaben mit einer Graphenstruktur. Desweiteren
findet sie häufig Anwendung bei der Darstellung von Aktionsfolgen (z.B.
Lösungswege).
109
Kapitel 2 Grundlagen
Prädikatenlogische Repräsentation
Alle bisher genannten Repräsentationsformen können auf Prädikate abgebildet werden. Man benötigt hierzu Elementarsymbole (logische Zeichen, Funktionszeichen, Prädikatzeichen und Variablen), Terme und Formeln. Zur Erinnerung folgt eine kurze Definition von Termen und Formeln:
1. Defintion von Termen:
a) Alle Variablen und 0-stelligen Funktionszeichen sind Terme.
b) Wenn t1 ,...,tn Terme und f ein n-stelliges Funktionssymbol ist mit
n > 0, dann ist f (t1 , .., tn ) ein Term.
c) Alle Terme entstehen aus (a) durch Iteration von (b).
2. Defintion von Formeln:
a) Wenn P ein n-stelliges Prädikatszeichen ist und t1 , ..., tn Terme
sind, dann ist P (t1 , ..., tn ) eine Formel (Atomformel).
b) Wenn F und P Formeln sind, dann sind auch ¬F , F ∨ P , F ∧ P ,
F ⇒ P Formeln.
c) Alle Formeln entstehen aus (i) durch Iteration von (ii).
Greifen wir das Beispiel der Attribut-Wert-Repräsenation auf, so kann man
folgende Beschreibung des Falls vornehmen:
Problem:
spannung(ausgang, 14.5) ∧ relais(1, on) ∧ relais(2, of f ) ∧ led(23, on)
Lösung:
⇒ def ekt(IC − 568)
Die prädikatenlogische Repräsentation ist sehr flexibel und kann auch für
Systeme mit hoher Komplexität verwendet werden. Die Theorie bietet auch
hier eine gute Grundlage. Jedoch gibt es Schwierigkeiten bei der Darstellung
von numerischen Werten. Man sollte vorher prüfen, ob die spätere Ähnlichkeitsbestimmung nicht zu aufwendig wird.
110
2.8 Fallbasiertes Schliessen
2.8.4 Ähnlichkeitsbestimmung
Das zentrale Thema des fallbasierten Schliessens ist die Ähnlichkeitsbestimmung. Sie ist notwenig für die Auswahl eines Falles - sie beantwortet die
Frage, ob ein Problem A auf das Problem B übertragen werden kann.
Problemstellungen
Zunächst soll hier darauf eingegangen werden, welche Fragestellungen und
Probleme zu beachten sind, wenn man eine Ähnlichkeitsbestimmung vornehmen möchte:
Eine absolute Ähnlichkeit wird es in den meisten Systemen nicht geben. So
ist die Toleranz der Abweichungen von großer Bedeutung. Wichtig ist zu bedenken, wann ein Objekt A tatsächlich dem Objekt B ähnlich ist. Dabei ist
es wichtig zu wissen, dass die einzelnen Attribute unterschiedliche Gewichtung haben können. Nicht jedes Attribut ist von gleicher Bedeutung. Diese
Gewichtung kann mit einer Zahl zwischen 0 und 1 angegeben werden.
Als Ergebnis müssen ggf. mehrere Fälle ausgewählt werden, damit der Anwender eine eigene Selektion vornehmen kann. So will der Anwender unter
Umständen zwischen mehreren Alternativen wählen können. Daraus folgt,
dass die Toleranz der Ähnlichkeit parametrisierbar sein muß.
Unter Umständen müssen für die Ähnlichkeitsbestimmung Attributwerte
umgeformt werden. Dabei darf deren Ordnungsinformation nicht verloren
gehen: stark, mittel, weich wird zum Beispiel zu den Werten 3, 2, 1. Es gilt
hierbei stark < mittel < weich.
Ähnlichkeitsrelationen und Ähnlichkeitsmaße
Um die Ähnlichkeit zwischen zwei Attributwerten zu ermitteln, wird ein Distanzmaß eingesetzt. Die einfachste Form der Distanz ist der Betrag der
Differenz zweier Werte:
Distanz = |AttributwertF allX − AttributwertF allY |
(2.4)
Dies ist jedoch eine zu triviale Berechnung. In der Praxis möchte man Werte
im Intervall von 0 bis 1 für jedes einzelne Merkmal. So kann man die einzelnen Werte mit der Gewichtung multiplizieren und dann diese ermittelten
Werte zu einem Betrag summieren. Dieser Wert dient dann zum Vergleich
mit anderen Fällen in der Fallbasis.
111
Kapitel 2 Grundlagen
Definition: Ähnlichkeitsmaß
Ein Ähnlichkeitsmaß auf einer Menge M ist eine reellwertige Funktion
sim : M 2 → [0, 1]
(2.5)
mit:
• ∀x ∈ M : sim(x, x) = 1 (Ref lexivitaet)
• ∀x, y ∈ M : sim(x, y) = sim(y, x) (Symmetrie)
Definition: Distanzmaß
Ein Distanzmaß auf einer Menge M ist eine reellwertige Funktion
d : M 2 → IR+
(2.6)
mit:
• ∀x ∈ M d(x, x) = 0 (Ref lexivitaet)
• ∀x, y ∈ M d(x, y) = d(y, x) (Symmetrie)
Ein Distanzmaß d ist eine Metrik und (M, d) bildet einen metrischen Raum,
wenn zusätzlich gilt: ∀x, y ∈ M : d(x, y) = 0 → x = y und ∀x, y, z ∈ M :
d(x, y) + d(y, z) ≥ d(x, z) (Dreiecksungleichung).
Folgend sollen zwei Ähnlichkeitsmaße definiert werden. Es handelt sich zum
einen um den Hammingabstand und zum anderen um den Simple-MatchingKoeffizienten:
Definition: Hammingabstand
H(x, y) = n −
n
X
i=1
xi · yi −
n
X
(1 − xi ) · (1 − yi )
(2.7)
i=1
Die Funktion hat folgende Eigenschaften:
• H(x, y) ∈ [0, n], wobei n der maximale Abstand ist
• H(x, y) bezeichnet die Anzahl der verschiedenen Attributausprägungen
• H ist ein Abstandsmaß. Hier gilt H(x, x) = 0 und H erfüllt die Symmetrieeigenschaft.
112
2.8 Fallbasiertes Schliessen
• H ((x1 , ..., xn ) , (y1 , ..., yn )) = H ((1 − x1 , ..., 1 − xn ) , (1 − y1 , ..., 1 − yn ))
Definition: Simple-Matching-Coefficient (SMC)
Die Formel des SMC ist etwas komplexer. Daher zunächst folgende Definitionen:
• a=
Pn
xi · yi
• b=
Pn
xi · (1 − yi )
• c=
Pn
− xi ) · yi
• d=
Pn
− xi ) · (1 − yi )
i=1
i=1
i=1 (1
i=1 (1
• n=a+b+c+d
Zunächst gilt: H(x, y) = b + c = n − (a + d)
Der SMC sei dann wie folgt definiert:
simH (x, y) = 1 −
n − (a + d)
a+d
b+c
=
=1−
n
n
n
(2.8)
Unter Umständen benötigt man Modifikationen der Ähnlichkeitsfunktion.
Dies ist zum Bespiel notwendig, wenn eine Ähnlichkeit bei einer Ausprägung
nur dann vorhanden ist, wenn beide einen bestimmten Wert erfüllen. Ähnlichkeit soll bespielsweise nur dann vorhanden sein, wenn beim Vergleich
zweier Autos beide Motoren defekt sind. Liegt in beiden Fällen kein Defekt
vor, so soll hier auch keine Ähnlichkeit bestehen. Kurz gesagt, hängt sim
in unterschiedlicher Weise von den Ausprägungen der einzelnen Attribute
ab. Nur ein Wert von ’1’ trägt demnach zur Ähnlichkeit bei. Ein mögliches
a
Ähnlichkeitsmaß in diesem Fall wäre die folgende Formel: sim = a+b+c
Eine weitere Modifikation ist notwendig, wenn Attribute von unterschiedlicher
Bedeutung für die Ähnlichkeit ist - wenn sim also in unterschiedlicher Weise
von den einzelnen Attributen abhängig ist. Bei einem Vergleich zweier Computersysteme ist das Attribut ’CPU’ wichtiger als das Attribut ’CD-ROM’.
Hier erweitert man den Hammingabstand um eine Gewichtung. Dabei steht
man vor der Schwierigkeit, den Gewichtsvektor bestimmen zu müssen. Dies
kann unter Umständen Kopfzerbrechen bereiten. Der Gewichtsvektor sei wie
folgt definiert: α = (α1 , ..., αn ) mit:
•
Pn
i=1
αi = 1
• αi ∈ [0, 1]
113
Kapitel 2 Grundlagen
Der gewichtete Hammingabstand ergibt sich dann aus der Formel:
Hα (x, y) = 1 −
n
X
i=1
αi · xi · yi −
n
X
αi · (1 − xi · (1 − yi )
(2.9)
i=1
Eine weitere Möglichkeit des Abstandsmaßes ist der gewichtete Abstand nach
Euklid. Dieser ist im Gegensatz zum Hammingabstand und dem SMC sehr
einfach:
v
u n
uX
αi · (xi − yi )2
(2.10)
d(x, y) = t
i=1
Verhalten bei unbekannten Attributwerten
Die große Stärke beim fallbasierten Schließen ist, dass trotz ungenauer Anfragen eine akzeptable Antwortmenge erzeugt wird. Fehlen Attributwerte, so
gibt es drei Strategien, mit den fehlenden Angaben umzugehen. Zur Erinnerung soll hier erwähnt werden, dass das Ähnlichkeitsmaß einen Wert im
Intervall von ”0” und ”1” hat. Im Falle hundertprozentiger Übereinstimmung
beträgt dieser Wert ”1”.
Bei der optimistischen Strategie geht man davon aus, dass es bei diesem
Merkmal zu einer Übereinstimmung kommen wird. Daher wird der Wert des
Ähnlichkeitsmaßes auf den Wert ”1” gesetzt. Die pessimistische Strategie
geht im Gegensatz dazu von absolut keiner Übereinstimmung aus. Der Wert
wird hier auf ”0” gesetzt. Die letzte Strategie nennt man ”Strategie des Erwartungswertes”. Für den fehlenden Attributwert wird ein wahrscheinlicher
Wert ermittelt. Mit diesem wird dann die Ähnlichkeit bestimmt.
Ähnlichkeitsbestimmung der Fallrepräsentationen
Widmen wir uns nun der Ähnlichkeitsbestimmung bei den unterschiedlichen
Fallrepräsentationen. Zunächst soll das Beispiel für die objektorientierte Repräsentation ergänzt werden:
Zunächst werden die Distanzen der einzelnen Attributwerte in den jeweiligen
Objektklassen berechnet. Wie diese Berechnung in diesem Fall genau erfolgt,
soll vernachlässigt werden. Die Werte werden jeweils mit der festgelegten Gewichtung multipliziert. Anschließend kann dann die Summe gebildet werden,
die nun die Distanz für die jeweilige Klasse ist. In diesem Fall erhält man
die Werte ”0,62” für die Oberklasse und ”0,97” für die Unterklasse. Fehlende Werte werden mit Hilfe der optimistischen Strategie verarbeitet. So wird
angenommen, dass es bei der Anfrage zu einer Übereinstimmung mit dem
114
2.8 Fallbasiertes Schliessen
Abbildung 2.40: Beispiel für eine OO-Repräsentation mit Gewichten und Distanzmaßen
Fall kommt. Das Distanzmaß wird also auf den Wert ”1” gesetzt.
Liegt eine Baumstruktur vor, so kann die Ähnlichkeit leicht an Hand von
der Position der beiden Vergleichskomponenten im Graphen bestimmten:
Hier ist zum Beispiel der Duron dem Athlon ähnlicher, als zum Pentium IV.
Abbildung 2.41: Beispiel einer Baumstruktur
Dies ist damit begründet, weil der Duron und der Athlon einen gemeinsamen
Vaterknoten besitzen.
Die Ähnlichkeitsbestimmung bei Graphen beruht auf Tests auf Graphenisomorphie. Zwei Graphen G1 = (N1 , E1 ) und G2 = (N2 , E2 ) sind isomorph,
wenn es eine bijektive Abbildung f : N1 7−→ N2 gibt, so dass gilt: (v, w) ∈ E1
gdw. (f (v), f (w)) ∈ E2 .
Das folgende Beispiel zeigt zwei isomorphe Graphen.
115
Kapitel 2 Grundlagen
Abbildung 2.42: Graphenisomorphie
2.8.5 Aufgabenklassen für fallbasierte Systeme
Bei einem fallbasierten System unterscheidet man analytische und synthetische Aufgaben. Bei analytischen Aufgaben liegt der Schwerpunkt der Anwendung in der Analyse einer vorliegenden Situation. Dazu muß ein vorliegender
Fall häufig einer Klasse zugeordnet werden. Diese Klassen sind im Allgemeinen fest vorgegeben. Eine Modifiziertung der Lösung ist hier nicht erforderlich. Hauptsächlich benötigt man lediglich nur die Ähnlichkeitsbestimmung.
Folgende Aufgaben gehören zu den analytischen Aufgaben:
• Klassifikation
• Diagnose
• Bewertung
• Entscheidungsunterstützung
Bei synthetischen Aufgaben liegt der Schwerpunkt im Zusammensetzen einer
komplexen Lösung aus einzelnen Bestandteilen. Die Anfrage ist hier in der
Regel eine Anforderung an eine Lösung. Die Lösungsmenge ist nicht begrenzt.
Ein wesentlicher Bestandteil des Systems ist die Lösungsanpassung. Dazu ist
eine große Fallbasis nötig. Die Entwicklung eines synthetischen Systems ist
deutlich höher als bei einem analytischen Systems. Folgende Aufgabenbereiche gehören zu dieser Klasse:
• Konfiguration
• Design
• Planung
116
2.8 Fallbasiertes Schliessen
2.8.6 Bezug zum Projekt ’DIONE’
Der Aufbau einer Fallbasis ist in unserem Fall nicht notwendig, da wir mit
der LEDA-Datenbank ohne weiteres arbeiten können. Der Anwender nutzt
das fallbasierte Schließen zur Ermittlung fehlender Attributwerte von Pflanzenmerkmalen. Die Eingabe ist eine Pflanze mit fehlenden Merkmalswerten.
Der Algorithmus führt eine Ähnlichkeitsbestimmung durch und gibt als Resultat Werte für die fehlenden Merkmale aus. Dabei sollte der Anwender eine
zusätzliche Information über die Qualität der ermittelten Werte bekommen
- also eine Aussage über den Grad der Ähnlichkeit.
Abbildung 2.43: Mögliche Nutzung des fallbasierten Schließens
Die vorhandenen Attributwerte in der LEDA-Datenbank können problemlos zur Ähnlichkeitsbestimmung verwendet werden, da es sich um nummerische Werte handelt. Durch die Struktur der Datenbank und der verwendeten Sprachen liegt es nahe, eine objektorientierte Ähnlichkeitsbestimmung
zu wählen. Die einzelnen Objektklassen werden also zunächst separat ausgewertet. Anschließend erfolgt eine Zusammenfassung der Werte zum Gesamtähnlichkeitsmaß. Das Ähnlichkeitsmaß kann durch eine relativ einfache
Abstandsberechnung bestimmt werden. Jedoch spielt die Gewichtung hier
eine große Rolle. Diese dürfte nicht ganz einfach umzusetzen sein.
117
Kapitel 2 Grundlagen
2.8.7 Vor- und Nachteile des fallbasierten Schließens
Die Wartung des Systems, insbesondere der Fallbasis, ist minimal. Das System kann neue Fälle selbständig aus den modifizierten Antwortfällen in die
Fallbasis übertragen. Somit wird neues Wissen automatisch hinzugefügt. Die
Benutzerakzeptanz ist sehr hoch, da die Vorgehensweise des fallbasierten
Schließens sehr natürlich ist. Jeden Tag vergleichen wir vorhandene Probleme mit zuvor gemachten Erfahrungen. Ein besonderer Vorteil liegt in der
hohen Ausnutzung der bestehenden Datenmenge. Das Prinzip erlaubt auch
relativ unscharfe Anfragen, also fehlende Attributwerte. Man erhält dennoch
eine Menge von Antworten, die akzeptabel ist. Wie bereits erwähnt, kann
man ein fallbasiertes System mit der Möglichkeit ausstatten, die Parameter
von Ähnlichkeitsmaßen zu lernen. Dazu benötigt man jedoch ein Feedback
vom Benutzer, der die ausgegebenen Lösungen bewerten muß.
Leider gibt es aber auch einige Nachteile, die hauptsächlich die Entwicklungsphase betreffen. So ist die Definition der Ähnlichkeitsmaße sehr aufwändig.
Oft kommt man um Probieren und Spielen mit den Gewichten nicht herum. Ein weiterer Nachteil ist, dass in den meisten Fällen ein Aufbau einer
Fallbasis nötig ist.
118
2.9 Das Softwarepaket SPSS Clementine 7.2
2.9 Das Softwarepaket SPSS Clementine 7.2
von Jörn Künnemann
2.9.1 Einleitung
In dieser Ausarbeitung geht es um das Softwarepaket Clementine von der
Firma SPSS. Hierbei soll gezeigt werden, welche Möglichkeiten eine DataMining Software bietet und wie die Handhabung dieses Programms ist. Als
Version wurde Clementine 7.2 benutzt.
2.9.2 Das CRISP-Datenmodell
Abbildung 2.44: Das CRISP-Datenmodell
Clementine baut auf dem CRISP-Datenmodell (Abbildung 2.44) auf, welches die Grundlage für die Realisierung von Projektplänen im bereich DataMining ist, wobei CRISP die Abkürzung für Cross Industry Standard for
Data-Mining ist. Erstellt wurde dieses standardisierte Prozessmodell von
verschiedenen Industriefirmen wie SPSS, OHRA und Daimler Chrysler anfang 1999. Ziel bei der Erstellung dieses Entwurfes war es, ein robustes,
119
Kapitel 2 Grundlagen
allgemeines Modell zu entwickeln, welches die Kosten- und Zeit minimiert,
Toolunabhängig ist, und eine Hilfe bei Dokumentation, Argumentation und
Wissensmanagement bietet. Der Vorteil liegt darin, das man durch die Standardisierung ein leichteres Verständnis für alle Beteiligten bekommt, bessere
Ergebnisse vorliegen und eine bessere Kommunikation nach außen hat. Vergleichbar ist dieses Modell mit Virtuous Cicle, KDD-Prozess und SEMMASAS. Es gibt sechs verschiedenen Phasen, welche zyklisch durchlaufen werden.
1. Business Understanding
2. Data Understanding
3. Data Preparation
4. Modeling
5. Evalution
6. Deployment
In der ersten Phase Business Understanding geht es um das Projektziel und
die Erfolgskriterien. Bsp. für ein Mobilfunkanbieter: “Durch die Kundenbindungsmaßnahmen soll die Kündigungsrate im Bereich Handy Privatkunden
von 20% pro Jahr auf 15% gesenkt werden.“ Das Unternehmen macht sich
einen Überblick über die Ressourcen, bezieht Risiken mit ein und stellt Kosten und Nutzen in Vergleich. Weiterhin wir das eigentlich Data-Mining Ziel
beschrieben, um das Erfolgskriterium zu erfüllen: “Um das Geschäftsbezogene Ziel zu Erreichen, sollen Kündiger vorab mit einer Genauigkeit von 80%
als solche identifiziert werden.“ Der letzte Schritt dieser Phase ist das erstellen eines Projektplanes wobei man sich hier einen ersten Überblick über
die vorhandenen Tools verschafft und die geeigneten Methoden zur Zielerreichung bewertet. Außerdem müssen noch weitere Einzelheiten geklärt werden.
In diesem Beispiel könnte das folgendermaßen aussehen:
• Einteilung der Kunden in einer Gruppe, wann ist ein Kunde ein Kündiger
• Festlegung eines Zeitrahmens, d.h. wann will ich mit dem Projekt beginnen und wann mache ich die nächsten Schritte
• Wann ist die Kampagne ein Erfolg
• Wie sieht es mit der Personellen Situation aus, verfüge ich über die
nötigen Experten um Datenbank und andere Programme zu bedienen
120
2.9 Das Softwarepaket SPSS Clementine 7.2
• Brauche ich zusätzliche Hard- oder Software
• Wo liegen die Grenzen des Projektes, welche Rechte muss ich einhalten,
z.B. Datenschutz, in welchen räumlichen Kreis kann ich die Aktion
durchführen
Nach dem Abschluss dieser Phase beginnt man mit Data Understanding.
Hierbei geht es um die Sammlung aller Daten die für das Projekt gebraucht
werden. Dabei kommen folgende Fragestellungen zustande:
• Wo kann ich auf die Daten zugreifen
• Muss ich mir Zugriffsrechte besorgen
• Wie steht es um die Qualität der Daten aus (Vollständigkeit)
• Gibt es noch weiter Informationsquellen auf die ich aber momentan
nicht zugreifen kann
Bei der Auswahl der Daten aus verschiedenen Quellen ist darauf zu achten, dass diese auch kompatibel zueinander sind. Unterschiede kann es z.B.
bei Datumsformaten geben (15-03-2004 oder 03-15-2004). Des Weiteren verschafft man sich einen ersten groben Überblick der Daten und stellt Zusammenhänge fest. Dieses geschieht damit, dass man sich die Daten in einer
Tabelle betrachtet oder sie in verschiedenen Grafiken darstellt. Aufgabe in
dieser Phase ist es auch, einen Datensammelungsbericht zu schreiben. In Phase drei, der Data Preperation, geht es um die Bereinigung der Datensätze. Es
werden die benötigten Daten erfassen und wichtige Felder und Variablen herausgesucht. Des weiteren werden die Datensätze von den so genannten Nullund Leerfeldern bereinigt oder aber auch mehrere Datensätze zu einem zusammengefügt. Hier entsteht also eine gründliche Analyse des Datenbestandes. Bei der Modellierung geht es um die Auswahl des richtigen Vorhersageund Erklärungsmodells. Es wird ein Verfahren bestimmt, zu dem man Testdaten entwickelt. Diese Testdaten sind nur ein kleiner Teil des wirklichen
Datenbestandes. Mit diesen Testdaten wird dann die Modellierung erzeugt
und schließlich bewertet. Ziel ist es, ein Modell zu finden, das nicht nur für die
Testdaten gute Ergebnisse bestimmt, sondern auch für den kompletten Datenbestand brauchbare Ergebnisse liefert. In der Evalution kommt es dann
zur Auswertung der Ergebnisse die man mit der Modellierung bekommen
hat. Hierbei muss genau darauf geachtet werden, ob auch wirklich das Projektziel erreicht wurde. Alle vorherigen Phasen werden noch einmal kritisch
betrachtet um dann die nächsten Schritte zu planen. Die letzte Phase ist
dann das Deployment, wo die Ergebnisse in der Realität umgesetzt werden.
121
Kapitel 2 Grundlagen
Die gesamte Umsetzung muss überwacht werden und endet mit einem finalen
Bericht. Clementine bietet zur Realisierung dieses Modells ein Hilfesystem
an, damit das Projekt möglichst dicht an diesem Prozess realisiert wird.
2.9.3 Die Arbeitsoberfläche von Clementine
Die Arbeitsoberfläche (Abbildung 2.45) von Clementine ist sehr einfach und
übersichtlich gestaltet. Sie besteht aus zwei Hauptbestandteilen, einmal die
Arbeitsfläche und einmal die so genannten Knoten. Auf der Arbeitsfläche
werden die Knoten über Pfeile verbunden und stehen somit in einer Beziehung zueinander. Die dadurch entstehenden Graphen nennt man Streams.
Das Platzieren der Knoten auf der Arbeitsfläche geschieht nach dem Dragand-Drop verfahren, sie können einfach mit der linken Maustaste auf den
gewünschten Platz der Arbeitsfläche gezogen werden oder alternativ mit einem Doppelklick der linken Maustaste platziert werden. Die Verbindungen
zwischen den einzelnen Knoten entstehen dadurch, das die mittlere Maustaste am Anfangsknoten gedrückt wird und am Endknoten wieder losgelassen
wird. Clementine bietet außerdem die Möglichkeit, mehrere Streams gleichzeitig geöffnet zu haben. Zwischen den einzelnen Streams kann man im Auswahlfenster wechseln, wo des weiteren noch die Ergebnisse der Modellierung
aber auch die Grafische Darstellung der Daten anwählbar ist. Wie die meisten
anderen Programme mit einer GUI bietet auch Clementine eine Menüleiste
am oberen Fensterrand wo bequem alle Befehle ausgeführt werden können.
Mit der rechten Maustaste kann man je nachdem an welcher stelle man sich
auf der Arbeitsoberfläche befindet unterschiedliche Kontexmenüs aufrufen.
Alle für das angeklickte Objekt möglichen Befehle werden hier dargestellt.
2.9.4 Die einzelnen Knoten
Die Knoten sind die Hauptbestendteile von Clementine. Mit Ihnen kann
man Datenquellen öffnen, bearbeiten und sich den Inhalt anzeigen lassen.
Getrennt sind die verschiedenen Knoten hierbei nach ihren Fähigkeiten wie
Import, Datensatzoperationen, Feldoperationen oder Ausgabe. Aus welchem
Bereich die platzierten Knoten kommen, kann man auf der Arbeitsfläche an
ihren unterschiedlichen Formen erkennen.
Import aus Datenquellen
In Clementine gibt es verschiedene Wege vorhandene Datenquellen zu importieren, sei es aus einer Datenbank, einer Textdatei oder aus dem eigenen
122
2.9 Das Softwarepaket SPSS Clementine 7.2
Abbildung 2.45: Die Arbeitsoberfläche
Programmformat von SPSS. Die vorhandenen Möglichkeiten sollen hier genauer beschrieben werden.
Datenbank: Mit diesem Knoten können Daten über ODBC importiert werden. Unterstützt werden hierbei Excel, MS Access, DBase, SAS, Oracle
und Sybase.
Datei(var.): Hier liest Clementine die ASCII-Daten aus einer Textdatei ein.
Die verschiedenen Spalten werden hierbei durch Trennzeichen gekennzeichnet. Vor dem Import ist bei den Einstellungen darauf zu achten,
welche Trennzeichen in der Textdatei benutzt werden. Die verschiedenen Möglichkeiten sind unter anderem Komma, Semikolon oder Tabulator.
Datei(fest): Hier liest Clementine die ASCII-Daten aus einer Textdatei mit
fester Spaltenbreite ein. Sobald eine bestimmte Anzahl von ASCIIZeichen erreicht ist, wird eine neue Spalte gebildet. Die Spaltenbreite
kann hierbei beliebig eingestellt werden, aber auch automatisch erkannt
werden.
SPSS-Datei: Hiermit können Daten importiert werden, die als SPSS-File
gespeichert wurden. Es ist auch möglich, Daten aus älteren Clementine
Versionen zu importieren.
SAS: Hiermit ist es möglich SAS-Daten zu importieren. Dabei kann man
123
Kapitel 2 Grundlagen
zwischen den Formaten SAS für Windows, SAS für UNIX, SAS Transport File und SAS version 7/8 auswählen.
Benutzereingabe: Hier ist eine manuelle Eingabe der Daten möglich. Dieses
kann dazu benutzt werden, eine kleine Testmenge für die Modellierung
herzustellen.
Datensatzoperationen
Mit den importierten Datensätzen können verschiede Operationen ausgeführt
werden. Dieses ist für die Phasen Data Understanding und Data Preperation
sehr wichtig.
Auswählen: Bei dem Knoten Auswählen werden nur Felder weiterverarbeitet, wenn diese eine bestimmte Bedingung erfüllen, beispielsweise Sollen nur Kunden betrachtet werden die älter als 40 Jahre sind. Als Bedingung müsste man folgendes einsetzen: “age > 40“, wobei age den
Feldnamen bezeichnet für den die Bedingung zutreffen soll.
Stichprobe: Hierbei handelt es sich um einen Knoten der eine Datensatz
auf eine bestimmt Größe reduziert, z.B. werden nur die ersten 50 Datensätze, jeder dritte oder 20 willkürliche ausgewählt. Dieser Knoten
wird häufig für das erstellen von einer Testmenge benutzt.
Aggregieren: Hiermit werden bestimmte Datensätze in einer Gruppe eingeteilt, z.B. gibt es in einer Tabelle die Spalten Alter, Geschlecht und Region. Möchte man nun wissen wie das Durchschnittsalter getrennt nach
Region und Geschlecht ist, so werden alle mit männlichem Geschlecht
einer Region in einer Gruppe zusammengefasst und das Durchschnittsalter errechnet. Das selbe passiert mit den weiblichen Geschlecht bis
alle auf ihre Region eingeteilt sind.
Sortieren: Hiermit ist es möglich die Daten aufsteigend oder absteigend bedingt durch ein oder mehrere Felder zu sortieren.
Mergen: Mit diesem Knoten ist es möglich mehrere Datenquellen zu einer
zusammenzufügen. Hierbei kann man zwischen zwei Verfahren des zusammenfügens auswählen.
1. Die Datensätze werden einfach in der vorhandenen Reihenfolge
nebeneinander gesetzt.
2. Es wird ein Schlüsselfeld in jeder Datenquelle definiert, damit jeder Datensatz genau zugeordnet werden kann.
124
2.9 Das Softwarepaket SPSS Clementine 7.2
Anhängen: Anders als beim Mergen, wo verschiedene Datenquellen spaltenweise zusammengefügt werden, kommt es hier zum Zusammenschluss
von Datensätzen zeilenweise. Die Datenquellen sind hierbei strukturell
gleich aufgebaut, jedoch unterschiedlich im Inhalt. Hierbei ist darauf zu
achten, dass die untereinander gehangenen Felder dem gleichen Feldtyp
entsprechen.
Bei Mergen und Anhängen kann es zu Problemen kommen. Diese treten
auf wenn die Datenquellen eine unterschiedliche Struktur im Aufbau
haben, da hiermit eine große Anzahl von leeren Feldern entstehen kann
und die Qualität der Daten damit deutlich zurück geht.
Duplikat entf.: Dieser Knoten bewirkt, dass man aus jeder Klasse nur einen
Repräsentativen Datensatz nimmt. Dieses könnte eingesetzt werden
um aus jeder Altersklasse beispielsweise nur eine Person zu nehmen.
Hierbei wählt Clementine jeweils den ersten Datensatz einer Klasse
aus, die restlichen Duplikate werden gelöscht.
Feldoperationen
Die Feldoperationen bieten verschiedene Möglichkeiten an, um die einzelnen
Felder zu manipulieren. Diese sind für die Qualitätssteigerung und für die
Phase Data Preparation notwendig.
Typ: Hierbei wird für die verschieden Felder der Typus festgelegt. Dieses ist
nötig, damit die verschiedenen Algorithmen der Modellierung mit den
Daten arbeiten können. Unterschieden wird hierbei zwischen Bereich,
Diskret, Flag(Binär) und Set. Bei dem Typ Bereich handelt es sich um
eine Eingrenzung numerischer Werte nach unten und nach oben, wobei
der Minimalwert des Datensatzes als untere und der Maximalwert des
Datensatzes als obere Schranke gewertet wird. Der Typ Flag kommt
zustande, wenn es nur zwei Auswahlmöglichkeiten für ein Feld gibt,
dementsprechend bietet Set die Auswahl mehrerer Möglichkeiten für
ein Feld an. In Diskret werden Felder eingeteilt, deren Inhalt viele
unterschiedliche String-Eingaben beinhaltet. Clementine bietet hierbei
die Möglichkeit, den Typ des Feldes automatisch zu erkennen oder aber
eine manuelle Festlegung.
Filter: Mit diesem Knoten kann man die für die Modellierung nicht benötigte
Felder löschen oder aber unpassende Feldbezeichnungen umbenennen.
Ableiten: Mit Ableiten werden neue Felder auf der Grundlage vorhandener
Felder erzeugt. Hierbei kommen die einfachen Rechenoperationen wie
125
Kapitel 2 Grundlagen
dividieren oder multiplizieren zum Einsatz. Um z.B. das Verhältnis
zweier Felder zueinander zu sehen, kann man mit dieser Operation
Feld1 durch Feld2 dividieren. Das entstandene Datenfeld wird als neue
Spalte dem Datensatz angehangen.
Füller: Der Füller ist ein wichtiger Bestandteil um den Feldinhalt zu verändern.
Hiermit kann man z.B. leere Felder automatisch mit Daten füllen. Hierbei muss man sich jedoch vorher im klaren sein, wie mit leeren Feldern
umgegangen werden soll. Dabei gib es drei Möglichkeiten:
1. Datensätze mit leeren Feldern werden gelöscht, dies hat den Nachteil das die Quelldatei sehr klein werden kann und somit unbrauchbar für eine Modellierung wird
2. Die leeren Felder werden mit Mittelwerten oder Modellwerten
gefüllt
3. Es wird ein Vorhersagemodell entwickelt, das die Felder mit dem
am wahrscheinlichsten für diesen Datensatz möglichen Werten
füllt. Hierbei wird überprüft, ob es einen ähnlichen Datensatz mit
dem gesuchten Wert gibt
Dichomatisieren: Hierbei wird eine Spalte mit Binärwerten eingefügt, die
anzeigt ob ein ausgewähltes Datenfeld zu einer Bestimmten Gruppe
gehört oder nicht. Zum Einsatz kommt dieser Knoten beispielsweise
bei einer Warenkorbanalyse. Produkte die gekauft wurden bekommen
eine 1, Produkte die nicht gekauft wurden bekommen eine 0.
Verlauf: Hierbei wird eine neue Spalte mit Feldern in einer sortierten Reihenfolge erzeugt. Dabei setzt Clementine immer den nächsten Wert
einer bestimmten Reihenfolge ins nächste Feld ein. Angewendet wird
dieses z.B. bei Datumsfeldern.
Diagramme
Die Diagramme liefern erste Zusammenhänge der Daten und einen graphischen Überblick der Roh-Daten. Des Weiteren sind die Diagramme zur Auswertung und Bewertung der Modellierung wichtig. Alle Diagramme sind im
Bildformat oder als HTML speicherbar und können somit bequem weiter
verwendet werden.
126
2.9 Das Softwarepaket SPSS Clementine 7.2
Modellierung
Hierbei möchte ich nicht auf die einzelnen Modellierungsarten in Detail eingehen, sondern nur darstellen, welche möglichen Verfahren in Clementine
angewendet werden können. Eine detaillierte Beschreibung der Modelle sind
in anderen Ausarbeitungen im Rahmen des Projektes Dione zu finden. Insgesamt bietet Clementine 12 verschiedene Versionen der Modellierung an:
• Neuronale Netze: Netzwerk & Kohonen
• Entscheidungsbäume: C5.0 & C&RT-Baum
• Clusteranalyse: K-Means & Two-Step
• Assoziationsanalyse Apiori & GRI
• Regressionsanalyse: Regression & Logistisch
• Sonstige: Sequenz & Faktor
Ausgabe
Mit diesen Knoten kann man sich Informationen über die Datensätze und
Modellierung anzeigen lassen. Genutzt werden diese Knoten in jeder Phase
des Crisp-Modells um in jeden Schritt möglichst viele Informationen zu gewinnen. Alle erzeugten Ausgaben kann man über das Ausgabefenster auf der
rechten oberen Hälfte der Arbeitsfläche aufrufen. Bei der Ausgabe kann man
zwischen Anzeigen auf dem Bildschirm und Ausgabe in ein File, wie z.B.
html, wählen. Die gespeicherten Files können dadurch bequem weiterverarbeitet werden. Zur einfachen Darstellung ist der Tabellen-Knoten gedacht.
Hier werden die Datensätze in einer einfachen Tabelle mit allen Datensätzen
angezeigt. Der nächste Knoten ist die Matrix, wobei hier die Daten in einer
Kreuztabelle angezeigt werden. In dieser Matrix kann man bereits erste Zusammenhänge der Daten erkennen. Mit dem Analyse-Knoten werden die fertigen Modellierungen unteranderem auf Richtigkeit überprüft. Hierbei wird
getestet, auf wie viel Prozent der Datensätze das Modellierungsergebnis zutrifft. Im angefügten Beispiel ist eine Richtigkeit von 100% erreicht wurden.
Dieses sind jedoch Traumwerte und werden in der Realität fast nie erreicht.
Der Statistik Knoten liefert wichtige Erkenntnisse über die Daten. Hierbei
kann man z.B. Datensätze erkennen, die für die Modellierung unwichtig sind.
Dieses könnten Felder sein, die mit ihren Werten von den anderen extrem
abweichen, und somit nicht repräsentativ für eine Modellierung sind. Der
Qualitätsknoten dient zur Überprüfung der Vollständigkeit des Datensatzes.
127
Kapitel 2 Grundlagen
Hierbei wird angezeigt, wie viel Prozent der Daten Leer-Felder oder Nullwerte sind. Der Report-Knoten dient dazu, einen ausführlichen Bericht zu
erstellen. Dabei kann automatisch generierter Text über die Daten und Modellierung eingefügt werden. Des weiteren ist ein Export der Daten in eine
Datenbank über ODBC möglich. Die Speicherung ins SPSS-Format bietet
eine einfache Weiterverarbeitung der Daten in andere Produkte von SPSS
an. Weiterhin gibt es die Möglichkeit der Speicherung in eine Textdatei und
ins Format von MS Excel.
Abbildung 2.46: Der Expression-Builder
2.9.5 Expression Builder
Der Expression-Builder (Abbildung 2.46) dient dazu, es dem Benutzer möglichst
einfach zu ermöglichen Formeln und Bedingungen zu erstellen. Aufrufen kann
man ihn überall dort, wo man Funktionen und Formel einsetzen kann. Der
Expression-Builder baut auf dem Sandkastenprinzip auf, was heißt, dass man
durch einfaches zusammenklicken komplexe Formeln erreicht. Auf der linken
Seite des Fensters sind hierbei die verschiedenen vordefinierten Formel zu
sehen, in der Mitte gibt es die einzelnen Grundrechenarten und Vergleichsoperationen, rechts im Fenster sind alle Felder eines Datensatzen inkl. Typ zu
sehen. Im oberen Fensterbereich sieht man die erstellten Formeln und Bedingungen, die man mit einem Mausklick auf “Überprüfen“ auf ihre Gültigkeit
überprüfen kann.
128
2.9 Das Softwarepaket SPSS Clementine 7.2
2.9.6 Beispiel
In diesem kleinen Beispiel sollen kurz die einzelnen Arbeitsschritte für die
Modellierung von Daten durchgenommen werden. Bei dem Datensatz handelt es sich um eine Medikamentenkartei mit verschiedenen Daten. Diese
sind Alter, Geschlecht, Blutnatriumkonzentration, Blutkaliumkonzentration,
Bluthochdruck und das verabreichte Medikament.
Abbildung 2.47: Patientenkartei
Ziel bei dieser Modellierung ist es, möglichst genau vorher zu sagen, bei
welchen Werten ein Patient welches Medikament einnehmen soll. Als erstes muss der Datensatz geöffnet werden. Dieses geschieht, in dem man den
Knoten Datei(var.) durch einen Doppelklick in der Knotenauswahl auf die
Arbeitsfläche bringen. Der so entstandenen Knoten wird mit einem Doppelklick der linken Maustaste geöffnet. Es erscheint ein Fenster mit mehreren Auswahlmöglichkeiten. Die zu öffnene Datei heisst “drug1n.txt“ und ist
bei jeder Standardinstallation von Clementin 7.2 vorhanden. Als nächstes
wird der Datensatz etwas genauer untersucht. Es wird ein Tabellen-Knoten
auf der Arbeitsfläche platziert und dieser wird mit dem Datensatzknoten
verbunden. Nach dem klicken mit der rechten Maustaste auf dem Tabellenknoten, erscheint ein Kontextmenü wo “Stream ausführen“ ausgewählt
129
Kapitel 2 Grundlagen
wird. Hierbei werden alle Schritte vom Anfangsknoten bis zum angeklickten
Endknoten durchgearbeitet. Nach dem Ende der Berechnung erscheint eine
Tabelle (Abbildung 2.47) mit den Rohdaten der Datenquelle. Hierbei kann
man sich einen kurzen Überblick der Daten verschaffen, genauere Aussagen über zusammenhänge kann man jedoch noch nicht treffen. Des weiteren
sieht man in der Tabelle die Vollständigkeit der Daten. Um einen besseren
Überblick über die Verteilung der Medikamente zu sehen, wird der Knoten
Verteilung eingefügt und ebenfalls mit dem Datensatz verbunden. Nach dem
Ausführen wird erkenntlich, welches Medikament wie häufig eingesetzt wurde (Abbildung 2.48). Hierbei wird deutlich, dass Medikament Y am meisten
Abbildung 2.48: Medikamentenverteilung
verabreicht wurde. Für die Verteilung der Medikamente sind in diesem Beispiel die Werte für Blutnatriumkonzentration und Blutkaliumkonzentration
sehr entscheidend. Um die Abhängigkeit der Medikamente im Zusammenhang mit diesen Werten darzustellen, wird ein Plot-Knoten erzeugt und mit
dem Datensatz verbunden. Bei den Eigenschaften wird als x-Achse die Spalte K und als y-Achse die Spalte Na zugeteilt. Als Farbe wird Medikament
eingestellt. Nach dem Ausführen des Streams erhält man ein Diagramm, wo
ersichtlich wird, das bei einem bestimmten Verhältnis von K zu Na nur ein
bestimmtes Medikament verabreicht wird. Mit den bisherigen Schritten hat
man einen ersten Überblick der Daten bekommen und durch die Darstellung
in Diagramme bereits erste Abhängigkeiten herausgefunden.
Um die Arbeitsfläche übersichtlich zu machen, können alle Knoten bis auf
die Datenquelle gelöscht werden. Für den weiteren Verlauf der Modellierung
sind diese nicht notwendig. Mit den Erkenntnissen aus den vorangegangenen Schritten wird der nächste Schritt vorbereitet. Es wird ein AbleitenKnoten auf der Arbeitsfläche erzeugt um ein neues Datenfeld im Datensatz
zu erstellen. Dieser wird wieder mit der Datenquelle verbunden und seine
Eigenschaften bearbeitet. Im Diagramm war ersichtlich, dass das Verhältnis
130
2.9 Das Softwarepaket SPSS Clementine 7.2
von K zu Na wichtig ist, und deshalb werden diese beiden Felder zueinander dividiert. Als neues Feld im Datensatz erscheint nun das Ergebnis dieser
Division, welches zur weiteren Verarbeitung verwendet wird. Als nächstes
wird das Ergebnis der neuen Spalte betrachtet (Abbildung 2.49), dazu wird
der Ableiten-Knoten mit einem Histogramm-Knoten verbunden. Dabei wird
ersichtlich, dass bei einem Verhältnis von über 15 zwischen N und K nur
Medikament Y in frage kommt. Um die Medikamente genauer einzuteilen,
Abbildung 2.49: Verhältnis von Na zu K
müssen aber noch andere Werte mit in Betracht gezogen werden. Mit einem
Netzdiagramm wird nun überprüft wie der Blutdruck die Medikamentenwahl
beeinträchtigt. Dabei wird erkenntlich, dass Medikament A, B und C nur bei
einer Art von Blutdruck verabreicht wird.
Mit den bisher gewonnenen Ergebnissen ist jedoch noch keine genaue Einteilung der Medikamente möglich. Um in der Modellierung fort zu fahren, wird
jetzt die genaue Datenauswahl getroffen. Mit dem Filter-Knoten werden die
für die Modellierung nicht benötigten Felder entfernt. In diesem Fall sind das
die Felder N und K, denn bei dieses Feldern interessiert nur das Verhältnis
dieser beiden untereinander. Als nächstes wird die Typesierung der Felder
mit dem Typ-Knoten festgelegt. Dieser wird mit dem Filter-Knoten verbunden und geöffnet. Die Festlegung des Typs wird hierbei automatisch ermittelt
in dem man den Knopf “Werte Lesen“ betätigt. Des weiteren wird hier noch
festgelegt, welches die Zielvariable ist. Da zu ermitteln ist, wann welches Mdikament eingesetzt werden soll, wird Medikament auch als Zielvariable in dem
131
Kapitel 2 Grundlagen
Feld Richtung eingestellt. Jetzt kommt es zur Auswahl des Modellierungsverfahrens, optimal für diesen Fall ist der Entscheidungsbaum C5.0 der auf der
Arbeitsfläche platziert wird und mit dem Typknoten verbunden wird. Um die
Modellierung abzuschließen, muss der fertige Stream (Abbildung 2.51) noch
einmal ausgeführt werden und das Ergebnis kann im Modellfenster betrachtet werden. Dazu wird auf dem neu entstandenen Knoten im Modellfenster
das Kontextmenü geöffnet und durchsuchen angewählt. Hierbei kann man
sich das Ergebnis einmal textuell als Baum (Abbildung 2.50) anzeigen lassen, oder aber die Graphische darstellung wählen. Um zu überprüfen ob die
Abbildung 2.50: Textuelle Baumdarstellung des Ergebnis
Modellierung ein akzeptables Ergebnis liefert, wird dieses mit dem AnalyseKnoten überprüft. Es wird hierbei der im Modellierungsfenster entstandene
Knoten mit dem Typ-Knoten verbunden und ein Analyse-Knote angehangen. Bei erneuten Ausführen des Streams wird erkenntlich, dass das Ergebnis
eine 100%ige Vorhersage für die Verteilung der Medikamente liefert, in der
Realität sind solche Ergebnisse jedoch höchst unwahrscheinlich.
132
2.9 Das Softwarepaket SPSS Clementine 7.2
Abbildung 2.51: Screenshot des fertigen Stream
2.9.7 Abkürzungen
SPSS: Statistical Package for the Social Sciences (Firmenname)
CRISP: Cross Industry Standard for Data Mining
KDD-Prozess: Knowledge Discovery in Database
SEMMA: Sample Explore Modify Model Access
MS: Microsoft
ODBC: Open DataBase Connectivity
133
Kapitel 2 Grundlagen
134
Kapitel 3
Anforderungsdefinition
Im Rahmen des EU-Projekts LEDA entsteht in der Abteilung Umweltinformatik eine Datenbank zur Speicherung von Pflanzendaten. Es werden dabei
für über 3000 Wildpflanzenarten Nordwesteuropas jeweils ca. 30 pflanzenphysiologische Merkmale unterschieden. Ziel der Projektgruppe ist es, aufbauend auf dem vorhandenen Informationssystem Komponenten zu entwickeln, die das Erkennen von Zusammenhängen zwischen Merkmalen auf physiologischer, räumlicher und umgebungsbezogener Ebene ermöglichen. Dazu
sollen verschiedene Methoden aus den Bereichen Data Mining, Clustering
und Machine Learning untersucht, implementiert und bewertet werden. Die
Integration einiger ausgewählter Algorithmen soll unter einer einheitlichen
Web-basierten Workbench erfolgen, die die Anwendung der Methodiken und
die Darstellung der Ergebnisse ermöglicht.
3.1 Vorgaben und Ziele
Als Basis dient eine bereits vorhandene Oracle-Datenbank, die über ca. 3000
Pflanzen mit 30 pflanzenphysiologischen Merkmalen verfügt. Es soll eine Webapplikation erstellt werden, die plattformunabhängig ist. Diese Applikation
soll es dem Benutzer des Internetportals möglich machen, Data-Mining zu
betreiben. Dazu werden einige Verfahren zur Verfügung gestellt, wie zum
Beispiel das Clustering oder die Erstellung eines Entscheidungsbaumes. Genauere Details der Funktionalität entnehme man den folgenden Ausführungen in diesem Dokument.
Ziel der Projektgruppe DIONE ist die Entwicklung einer Data-Mining-Workbench, die im realen Betrieb einer Web-basierten Datenbank (’LEDA’) mit
Pflanzenmerkmalen von externen Benutzern eingesetzt werden kann.
135
Kapitel 3 Anforderungsdefinition
3.1.1 Web-Applikation innerhalb eines Service-Containers
Die Implementierung der Algorithmen wird in der Programmiersprache Java
erfolgen und die einzelnen Module sollen als Web-Applikationen innerhalb
eines Servlet-Containers ablaufen. Als Server wird der Apache Tomcat 5.x
verwendet.
3.1.2 Entwicklungsumgebung
Die Implementierung erfolgt unabhängig vom Betriebssystem. Als Entwicklungsumgebung wird Eclipse in der Version 3.0 verwendet. Zusätzlich wird
das Tomcat Plugin von SYSDEO in der Version 3.0.0.alpha1 eingebunden.
Zur Versionskontrolle wird zudem CVS eingesetzt, das auch von Eclipse
unterstützt wird. Der Server ”polaris-neu.offis.uni-oldenburg.de”, der auch
den Zugriff auf die Oracle-Datenbank erlaubt, wird vom Softwarelabor zur
Verfügung gestellt.
3.2 Szenarien und Anwendungsfälle
Vorstellbare Szenarien für DIONE sind DataMining-Vorgänge, die von Forschern durchgeführt werden, welche zusätzliche Erkenntnisse über Pflanzenarten und deren möglichen Zusammenhänge unter Zuhilfenahme der Daten,
die in der LEDA-Datenbank gespeichert sind, erlangen wollen. Die Forscher
sind in der Regel gut bis sehr gut mit dem Datenbankschema(vgl. [4]) der
LEDA-Datenbank vertraut. Ihr Aufenthaltsort, von dem sie die DataMiningExperimente aus betreiben wollen, ist nicht bestimmt. Es ist aber davon auszugehen, dass sie über einen internetfähigen Personal Computer mit einem
nicht allzuschnellen Internetzugang verfügen, mit dem sie durch Verwendung eines graphischen Webbrowsers Zugang zum World Wide Web erlagen
können.
3.2.1 Akteure
Wie bereits erwähnt, kann davon ausgegangen werden, dass die Benutzer des
DIONE-Systems über gute Kenntnisse des LEDA-Schemas verfügen. Dagegen ist nicht gesichert, dass die selben Benutzer über große Computererfahrung verfügen. Aus diesem Grund sollte nur vorausgesetzt werden, dass die
DIONE-Benutzer fähig sind, selbständig ins World Wide Web über einen
Webbrowser zu gelangen. Die Webseiten, über die das DIONE-System durch
136
3.2 Szenarien und Anwendungsfälle
die Benutzer gesteuert werden kann, muss also weitestgehend selbsterklärend
sein, ergonomische Richtlinien erfüllen und wie eine normale“ Webseite da”
herkommen.
Dagegen kann die fachliche Kompetenz der DIONE-Benutzer bezogen auf
das Forschungsgebiet als sehr ausgeprägt vorausgesetzt werden. Es ist daher
nicht nötig, Hilfestellung aus biologischer Sicht zur Verfügung zu stellen.
3.2.2 Wesentliche Anwendungsfälle
DIONE
DataMining
Modell erstellen
Benutzer
DataMining
Modell verifizieren
Pflanze in Klasse einordnen
(Vorhersage)
Abbildung 3.1: Wesentliche Anwendungsfälle
Die wesentlichen Anwendungsfälle - vgl. Abbildung 3.1 - beschreiben plakativ
die drei wesentlichen DataMining-Vorgänge, welche aus den denkbaren Szenarien hervorgehen, welche allesamt innerhalb eines sog. Experiments durchgeführt werden können.
DataMining-Modell erstellen
Ein DataMining-Modell kann eine Klassenbeschreibung, ein Entscheidungsbaum oder auch eine Regelmenge sein. Ein solches Modell wird mit einer
Menge von Trainingsdaten“ (Menge von Pflanzen mit bestimmten betrach”
teten Merkmalsausprägungen) evtl. interaktiv mit dem Benutzer erstellt. Um
137
Kapitel 3 Anforderungsdefinition
z.B. eine Pflanze in eine Klasse mit einer gewissen Wahrscheinlichkeit zuordnen zu können, ist ein vorhandenes DataMining-Modell notwendig.
DataMining-Modell verifizieren
Um die Güte eines erstellten DataMining-Modells verifizieren zu können,
hat der Benutzer die Möglichkeit, das Modell mit Hilfe einer Menge von
Testdaten zu verifizieren. Diese Testdaten haben in der Regel den gleichen
Aufbau wie die Trainingsdaten (s.o.), beinhalten aber Werte, welche aber
zur Modellerstellung keine Verwendung gefunden haben.
Vorhersage
Schließlich hat der Benutzer die Möglichkeit, ein erstelltes DataMining-Modell
anzuwenden. Hierzu kann z.B. eine Pflanze auf einen Entscheidungsbaum
angewandt werden und eine Vorhersage gegeben werden, mit welcher Wahrscheinlichkeit die Pflanze in eine bestimmte Klasse fällt.
3.2.3 Weitere Anwendungsfälle
Die wesentlichen Anwendungsfälle werden - wie bereits erwähnt - jeweils
im Rahmen eines Experiments durchgeführt. Es folgen nun weitere Anwendungsfälle, welche sich auf die Handhabung dieser Experimente beziehen.
Plakativ dargestellt in Abbildung 3.2.
Konfiguration der Experimente
Zu einem Experiment gehört die Datenmenge ( Traitmatrix“), das verwen”
dete DataMining-Verfahren (z.B. Clustering, Entscheidungsbaum), die Anwendung (Modell erstellen, verifizieren bzw. Vorhersage) sowie am Ende das
Ergebnis. Die einzelnen Elemente eines Experimentes lassen sich je nach Art
unterschiedlich umfangreich konfigurieren. So könnte z.B. festgelegt werden,
wieviele Klassen beim Clusteringverfahren erstellt werden sollen. Auch lässt
sich die Traitmatrix genau bestimmen. Neben der genauen Angabe, welche
Pflanzen in der Datenmenge auftauchen sollen, kann auch bestimmt werden,
über welche Merkmale der Pflanzen das DataMining durchgeführt werden
soll.
138
3.2 Szenarien und Anwendungsfälle
Weitere DIONE Services
Konfiguration der Experimente
Aggregation der Quelldaten
Laden und Speichern von Experimenten
Benutzer
Scheduling von laufenden Experimenten
Exportieren / Veröffentlichen von Ergebnissen
Import von Klassenbeschrei
bungen
Abbildung 3.2: Die weiteren Anwendungsfälle
Aggregation der Quelldaten
Aufgrund der Gegebenheit, dass in der LEDA-Datenbank eine Menge von
Nullwerten (Merkmalsausprägungen ohne Eintrag) vorhanden sind, muss
dem Benutzer die Möglichkeit gegeben werden, die Quelldaten der Traitmatrix zu aggregieren. Hierzu zählt z.B. die Anwendung eines Nullwertverfahrens (z.B. Durchschnitt einsetzen, oder Zufallszahl) für ein Merkmal auf
alle nichtausgefüllten Merkmalsausprägungen.
Laden und Speichern von Experimenten
Alle an dem Experiment beteiligten Elemente (Quelldaten, Verfahren, Ergebnis) und ggf. deren Konfigurationen sollen abgespeichert und auch wieder
geladen werden können.
Scheduling von Experimenten
Der Benutzer soll die Möglichkeit haben, bei langwierigen Experimenten,
mehrere Experimente zu starten. Dazu gehört dann auch, dass er für deren
139
Kapitel 3 Anforderungsdefinition
Durchführung unterschiedliche Prioritäten festlegt und auch ggf. laufende
Experimente abbrechen ( killen“) kann.
”
Import von Klassenbeschreibungen
Es soll dem Benutzer die Möglichkeit gegeben werden, von ihm selbst erstellte Klassenbeschreibungen auf das System hochzuladen, welche dann als
Attribute der Quelldaten (Spalten in der Traitmatrix) gewertet werden, welche ausgehend von der nun hochgeladenen Datenbasis erweitert / modifiziert
werden kann.
Exportieren / Veröffentlichen von Experimenten / Ergebnissen
Wenn der Benutzer ein Experiment für spannend genug hält, dass sich auch
andere dafür interessieren künnten, so hat er die Möglichkeit, das Experiment
öffentlich“ zu machen, so dass auch andere Benutzer das Experiment laden
”
und nachvollziehen können.
Ebenso soll er einen Report über das Experiment erstellen können und Ergebnisse in einem gängigem Exportformat herunterladen können.
140
3.3 Prozessverläufe
3.3 Prozessverläufe
Konfiguration der
Verfahren
Eingabe
Verfahren 1
Vergleich der
Ergebnisse
Ausgabe 1
Interaktion
Verfahren 2
Ausgabe 2
Abbildung 3.3: Prozessverlauf Übersicht
Abbildung 3.3 zeigt eine grobe im Weiteren noch näher beschriebene Übersicht über den Prozessablauf des Data-Mining mit DIONE: Gefolgt von einer Eingabe von Daten können verschiedene konfigurierbare Data-Mining
Verfahren auf diesen Daten angewandt werden, und deren Ergebnisse miteinander verglichen werden. Für bestimmte Verfahren können die erreichten
Ergebnisse auch wieder als Eingabe dienen. Grundsätzlich ist vorgesehen,
dass bestimmte Data-Mining Verfahren maßgeblich interaktiv durch den Benutzer beeinflusst werden können.
141
Kapitel 3 Anforderungsdefinition
3.3.1 Verfahren
Speichern der Parametrisierung
Parametrisieren des Verfahrens
Laden von Verfahrens-Parametern
Ausfuehrung des Algorithmus
Interaktive Anpassung
Bestimmen der Trait-Matrix
Interne
Repraesentation
Darstellung des Ergebnisses
visuell
Speichern des Ergebnisses
Vergleich der Ergebnisse
Export der Ergebnisse
Intern
(Weiterverarbeitung)
Extern
(graphisch, Tabellenform, pmml etc.)
Abbildung 3.4: Prozessverlauf für Verfahren
Im folgenden sei der universale Prozessverlauf für die einzelnen Verfahren
beschrieben. Er beschreibt den Ablauf bei Auswahl einer der wesentlichen
Anwendungsfälle, die zuvor beschrieben wurden. Zunächst muss eine TraitMatrix bestimmt werden. Das System gibt anschließend die Möglichkeit, die
Parameter des Verfahren zu ändern oder eine bereits gespeicherte Konfiguration zu laden. Nach dem Laden können die Parameter noch verändert
werden. Die gewählte Konfiguration kann vor der Ausführung des Verfahrens
gespeichert werden. Nach Ausführung des Verfahrens kann das Ergebnis in
verschiedenen Repräsentationsformen ausgegeben werden. Dies ist stark vom
jeweiligen Verfahren abhängig. Anschließend kann das Ergebnis gespeichert
oder exportiert werden. Desweiteren besteht die Möglichkeit einen Vergleich
mit anderen Ergebnissen vorzunehmen. Der Ergebnisvergleich wird im Folgenden beschrieben.
142
3.3 Prozessverläufe
3.3.2 Trait-Matrix
Aggregation von Daten
Behandlung von Nullwerten
Auswählen von Merkmalen
Auswählen von Pflanzen
Speichern der Trait-Matrix
Laden einer Trait-Matrix
Hochladen einer Pflanzenliste
mit Attributen
Abbildung 3.5: Prozessverlauf Trait-Matrix
Das Bestimmen einer Trait-Matrix wird durch zwei wichtige Schritte bestimmt: Das Festlegen, welche Pflanzen in die Matrix aufgenommen werden
sollen, und das Auswählen von den Merkmalen für die Matrix. Der letztere Schritt schließt die Aggregation von Daten mit ein. Die beiden Schritte
Auswählen von Pflanzen“ und Auswählen von Merkmalen“ können in be”
”
liebiger Reihenfolge - auch sich gegenseitig unterbrechend - vorgenommen
werden. Alternativ kann auch eine bereits gespeicherte Trait-Matrix geladen
werden, welche wiederum verändert werden kann. Desweiteren soll es möglich
sein, die Trait-Matrizen abzuspeichern, damit sie in anderen Situationen erneut geladen werden können.
143
Kapitel 3 Anforderungsdefinition
3.3.3 Ergebnisvergleich
Durchführen eines
Qualitätsvergleichs
Ausgabe des Vergleichsergebnisses
Auswahl von Ergebnissen
Laden von Ergebnissen
Speichern der Ergebnisse
Abbildung 3.6: Prozessverlauf für Ergebnisvergleich
Die nachdem Anwenden eines Data-Mining-Verfahrens erzielten Ergebnisse
können mit anderen bereits vorhandenen Ergebnissen verglichen werden. Für
diesen Qualitätsvergleich können die entsprechenden Ergebnisse geladen und
ausgewählt werden. Es erfolgt eine Ausgabe des Vergleichsverfahrens.
3.4 Funktionale Anforderungen
3.4.1 Benutzerverwaltung
Registrierte Benutzer der Internetpräsenz haben uneingeschränkten Zugriff
auf alle in der LEDA-Datenbank enthaltenden Informationen und über die
zur Verfügung gestellten Data-Mining Algorithmen. Sie melden sich mit einem Benutzernamen und einem Passwort an. Das Benutzerprofil, das alle
notwendigen Informationen (e-Mail-Adresse, Vor- und Nachname) enthält,
kann von ihm geändert werden.
3.4.2 Management der Arbeitsabläufe
Da unter Umständen die Berechnungen des Data-Minings zeitaufwendig ist,
wird das Verfahren auch dann fortgesetzt, wenn der Benutzer sich abmeldet.
Ist das Verfahren abgeschlossen, erhält er eine Benachrichtigung per e-Mail.
144
3.4 Funktionale Anforderungen
Zudem verfügt das System über sogenannte ”persistente Sessions”: Der Arbeitsstatus bleibt nach dem Abmelden aus dem System erhalten.
3.4.3 Auswahl der Trait-Matrix
Zur Eingabe benötigt der Algorithmus unter anderem die Auswahl der Pflanzen mit den gewünschten Attributen (z.B. Trainings- oder Testmengen).
Diese können nach belieben ausgewählt werden. Nullwerte können dabei
mit verschiedenen Verfahren behandelt werden. Durch ein flexibles Suchsystem können die Pflanzen selektiert werden. So zusammengestellte Matrizen
können gespeichert und geladen werden.
3.4.4 Modellerstellung
Mit der Modellerstellung wird ein DataMining-Modell (z.B. ein Entscheidungsbaum) durch ein DataMining-Verfahren auf Basis einer Trainingsdatenmenge erstellt. Nach Auswahl eines der zur Verfügung stehenden Algorithmen, kann eine Konfiguration des Verfahrens vorgenommen werden. Dabei
wird dem Anwender eine Konfiguration empfohlen, die er seinen Bedürfnissen anpassen kann. Konfigurationen können gespeichert und geladen werden.
Anschließend erfolgt die Ausführung des Verfahrens.
3.4.5 Modellverifizierung
Mit der Modellverifizierung wird ein erstelltes DataMining-Modell (z.B. ein
Entscheidungsbaum) durch ein DataMining-Verfahren auf Basis einer Testdatenmenge verifiziert. Nach dem Laden eines zu verifiziereden Modells und
der Auswahl einer passenden Trait-Matrix kann die Verifizierung gestartet
werden. Die erstellte Modellverifizierung kann als Konfiguration geladen und
gespeichert werden.
3.4.6 Modellvorhersage
Durch die Modellvorhersage hat der Benutzer die Möglichkeit ein erstelltes
DataMining-Modell auf eine Pflanze anzuwenden. Hierfür muss ein bereits
erstelltes Verfahren geladen und eine Pflanze ausgewählt werden. Durch Starten des Verfahrens wird das Modell auf die gewählte Pflanze angewendet. In
der Darstellung des erzeugten Ergebnis wird z.B. durch Anwendung eines
145
Kapitel 3 Anforderungsdefinition
Entscheidungsbaums auf eine Pflanze eine Vorhersage gegeben werden, mit
welcher Wahrscheinlichkeit die Pflanze in eine bestimmte Klasse fällt.
3.4.7 Ergebnisausgabe
Nach der Ausführung eines Datamining-Verfahren kann sich der Benutzer
das Ergebnis darstellen lassen. Abhängig vom gewählten Verfahren wird das
Ergebnis dem Benutzer unterschiedlich präsentiert. Für ein Verfahren können
unterschiedliche Sichten auf das Ergebnis zur Verfügung stehen. Für Ergebnisse die auf gleiche Darstelllungen (z.b Regeln) abgebildet werden können,
sollten diese Darstellungen dem Benutzer zur Verfügung stehen.
3.4.8 Jobverwaltung
Dadurch das dem Benutzer die Möglichkeit gegeben wird nach dem Starten
eines Verfahrens weiter zu Arbeiten, kann er mehrere Verfahren gleichzeitig durch das System bearbeiten lassen. Die Anzahl von ihm angestoßenen
Verfahren muss dem Benutzer in jeder Sicht präsentiert werden. Er hat die
Möglichkeit sich über die laufenden Verfahren zu informieren und sie abzubrechen.
3.5 Nichtfunktionale Anforderungen
3.5.1 Latenzzeiten
Um ein das Benutzungs-Interface eines Software-Systems für den Nutzer
möglichst konfortabel und transparent zu gestalten, ist es notwendig, dass
Latenzzeiten auf ein Minimum reduziert werden. Nach Möglichkeit sollte der
Benutzer umgehend nach einer eigenen Aktion eine Reaktion des Systems
darauf erhalten - ggf. durch eine einfache Empfangsbestätigung der Eingabe.
Das Erreichen dieser Ziele ist bei Applikationen, die als Client-Server Architektur über ein Netzwerk (z.B. das Internet) arbeiten, eine Herausforderung:
Latenzzeiten treten bei der Datenübertragung, der Reaktion des Webservers
und der es Datenbankservers auf. Dazu kommen noch die ohnehin vorzunehmenden Berechnungsschritte wie z.B. das Aufbauen einer aktualisierten
GUI. Aufgrund der Wahl einer Webbrowser basierten Benutzungsschnittstelle können noch weitere Latenzzeiten wie z.B. das generelle Neuaufbauen der
kompletten aktuell angzeigten Webseite entstehen.
146
3.5 Nichtfunktionale Anforderungen
Die Reduzierung der Latenzzeiten muss aber im Einklang mit anderen software-ergnonischen Zielen wie der Benutzerführung und der Übersicht geschehen. Es muss ein Kompromiss zwischen möglichst wenig Serveranfragen und
einer zufriedenstellenden Benutzerführung gefunden werden.
3.5.2 Erweiterbarkeit
Durch eine konsequente Kapselung wird eine hohe Erweiterbarkeit garantiert. Die Benutzeroberfläche erhält die Anzeigeobjekte in der für die Anzeige nötige Form. Trotz der Entscheidung, lediglich die Algorithmen von Xelopes zu nutzen, ist eine spätere Verwendung von anderen Algorithmen ohne
hohen Aufwand möglich. Individuelle Programmierung erfordert jedoch die
Darstellung des Ergebnisses, da dies nicht universell zu definieren ist. Die
Ergebnisformen sind dafür zu unterschiedlich. Jedoch sei nochmal erwähnt,
dass eine Meta-Darstellung angestrebt ist.
3.5.3 Sicherheit
Grundsätzlich werden die allgemein geltenden Standards für Sicherheit in
der Softwaretechnik eingehalten. Der Schutz der Datenbank vor unberechtigten Zugriffen fällt nicht in den Zuständigkeitsbereich dieses Projektes.
Da minderrelevante, personenbezogende Daten zwischen Client und Server
übermittelt werden (Vor- und Nachname, e-Mail-Adresse) - jedoch keine besonders sensible Daten wie z.B. Bankverbindungsdaten - wird auch eine SSLVerschlüsselung verzichtet. Diese Entscheidung wurde auch getroffen, da dieses Verfahren einen negativen Einfluß auf die Übertragungsgeschwindigkeiten
hat.
3.5.4 Verfügbarkeit
Auf die Verfügbarkeit des Servers hat die ”PG DIONE” keinerlei Einfluss
und übernimmt daher auch keine Verantwortung. Jedoch wird bei der Entwicklung darauf geachtet, dass stabilitätskritische Programmaktionen, die
den Server in bedrohliche Zustände bringen könnten, vermieden werden.
3.5.5 Korrektheit
Data-Mining kann unter Umständen ein sehr komplexer Prozess sein. Daher
ist es möglich, dass aufgrund von häufigen Berechnungen mit Fließkomma-
147
Kapitel 3 Anforderungsdefinition
zahlen Ergebnisse durch Rundungsfehler verfälscht werden können. Diese
Möglichkeit besteht insbesondere dann, wenn es DIONE-Services gibt, welche Client-seitig ausgeführt werden können, da hier mit unterschiedlicher
ausführender Hardware operiert wird. Weitere Möglichkeiten der Ergebnisverfälschung bestehen, wenn Data-Mining-Verfahren mit Heuristiken arbeiten, die zufällige Werte verwenden.
Es kann also nicht garantiert werden, dass bei gleicher Dateneingabe und verschiedenen Berechnungsvorgängen auf ggf. unterschiedlichen Systemen immer auch das gleiche Ergebnis erzielt werden kann.
3.5.6 Kompatibilität
Es wird verlangt, dass die Webseiten von DIONE mit den Webbrowsern der
neuesten Generation mit der höchsten Verbreitung in möglichst einheitlicher
Optik funktionieren. Dazu werden die Webseiten in dem Format XHTML
”
1.0“ erstellt und anschließend mit einem entsprechenden Validator auf Konsistenz überprüft.
Eine vollständige Funktionsgarantie im Sinne der Anforderungsdefinition
wird allerdings nur für den Webbrowser Firefox ab Version 1.0 bzw. auf gleicher Technik basierender Netscape bzw. Mozilla-Browser bei Aktivierung von
JavaScript und Cookies gegeben. Diese Konfiguration ist Clientseitig als Referenz vorgesehen. Nichtverfügbarkeit von JavaScript kann zu Einschränkungen im Bedienkompfort führen. Webbrowser, die auf Technik von Opera, MSInternetExplorer, Safari oder anderen basieren, zeigen die DIONE-Seiten unter Umständen in abgewandelter Form an, sollten aber auch eine vollständige
Funktionalität ermöglichen. Auch kann es zu abgewandelter Anzeige kommen, wenn bestimmte Systemschriftarten nicht installiert sind. Als minimale
Bildschirmauflösung werden 1024 mal 768 Punkte vorrausgesetzt.
3.5.7 Haftung
PG DIONE“ übernimmt grundsätzlich nur Haftung im Rahmen der notwen”
digen gesetzlichen Bestimmungen. Die Nutzung der Softwareprodukte unterliegen zwar einer strengen Kontrolle, für Fehler und dadurch eventuell auftretende Datenverluste oder Einwirkungen auf betriebliche Arbeitsmöglichkeiten übernimmt ”PG DIONE” keine Haftung. Der Kunde kann bei Nachweis von grober Fahrlässigkeit bei der Programmierung des Softwareproduktes entsprechende Haftungsanforderungen stellen. ”PG DIONE” übernimmt
keine Haftung für sonstige Fehler, die seitens externer Software verursacht
148
3.6 Systemaufbau
wird (Viren, Betriebssysteme, Installationsprogramme, Datenbankhilfsprogramme). ”PG DIONE” oder Lizenzgeber, Direktoren, leitende Angestellte
oder Mitarbeiter haften in keinem Fall für etwaige direkte, indirekt verursachte oder gefolgte oder besondere Schäden (Gewinnverluste, Betriebsunterbrechung oder Verluste von Geschäftsinformationen usw.), die aufgrund
der Verwendung oder der Nichtverwendbarkeit der Software oder der begleitenden schriftlichen Materialien entstehen, unabhängig vom Grund des
Anspruchs und selbst wenn ”PG DIONE” oder ein Vertreter von ”PG DIONE” auf die Möglichkeit solcher Schäden hingewiesen wurde. ”PG DIONE”
übernimmt keine Garantie für die Erreichbarkeit des zur Verfügung gestellten Servers. Die Haftung im Bezug auf Fehler beim Server beschränkt sich
ausschließlich auf die Konfiguration des Serverprogrammes (Apache Tomcat
5.x), da ”PG DIONE” keinen Einfluss auf die Hardware oder das Betriebssystem (incl. Systemprogramme wie Firewalls) hat.
3.6 Systemaufbau
HTTP
Request
HTTP
Response
Web-Browser
Tomcat
Container
Präsentationsschicht
Anwendungs- Datamining
schicht
Algorithmen
Data-Access-Objects
Dione
Datenbank
SQL
Response
SQL
Request
SQL
LEDA
Datenbank
Abbildung 3.7: Aufbau des Systems
149
Kapitel 3 Anforderungsdefinition
Grundlage des Systems ist eine Three-Tier Architektur. Die drei Komponenten des sind ein auf dem Rechner des Benutzers laufender Web-Browser,
die in einen Tomcat Webserver eingbettete Kernkomponente und eine Datenbank die sowohl die Daten aus dem LEDA-Projekt als auch Dione spezifische
Daten enthält.
3.6.1 Web-Browser
Da für die erzeugung der Darstellung für den Benutzer Standard HTML eingesetzt wird, kann jeder moderne Browser wie z.B der Internet Explorer von
Microsoft in einer aktuellen Version oder Mozilla eingesetzt werde. Spezielle
Anforderungen wie installierte Plugins sind für die Grundfunktionen nicht
erforderlich.
3.6.2 Kernkomponente
Die in Java implementierte Kernkomponente läuft innerhalb des Web-ApplikationenContainer Apache Tomcat. Sie ist in vier Teile aufgeteilt
• Präsentationsschicht erzeugt mittels JSP’s und Servlets HTML-Seiten
• Anwendungsschicht steuert den Kommunikation zwischen den den anderen Komponenten
• Datamining Algorithmen dient zur Berechnung der Datamining Modelle
• Data-Access-Objects dienen zur Kapselung der Datenbank
Durch Kapselung der einzelnen Teile von einander wird eine erhöhte Flexibilität und Wartbarkeit erreicht.
3.6.3 Datenbank
Die LEDA-Daten und die Dione spezifischen Daten befinden sich in der selben Oracle Datenbank. Mittels SQL wird übers Netwerk auf sie zugegriffen.
150
3.7 Dokumentationsanforderungen
3.7 Dokumentationsanforderungen
3.7.1 Entwicklerdokumentation
Als Dokumentation für Entwickler dienen in erster Linie folgende Dokumente: Der Entwurf des Systems sowie der Javadoc der Implementierung.
Der Entwurf des Systems beinhaltet eine detaillierte Beschreibung des Aufbaus des Systems, welche bis zu Klassenbeschreibungen und -Diagrammen
sowie ggf. Datenbankschemata herunter reicht. Der Entwurf ist online als
PDF-Dokument in deutscher Sprache für Entwickler verfügbar. Die Möglichkeit des Ausdrucks ist damit gegeben. Bei der Umsetzung des Systems laut
Entwurf wird parallel zur Implementierung der Quelltext kommentiert. Dabei wird sich der Vorzüge des Javadoc-Systems bedient, welches das Erstellen einer HTML-Dokumentation über die Klassenstruktur des Systems unterstützt. Diese Dokumentation wird in deutscher Sprache für die Entwickler
online zur Verfügung gestellt. Die Möglichkeit, einen Ausdruck davon zu erstellen, ist aber stark eingeschränkt.
3.7.2 Endbenutzerdokumentation
Die Dokumentation für den Endbenutzer wird als PDF-Dokument erhältlich sein. Zudem wird ein umfangreiches Hilfesystem auf den Internetseiten
zur Verfügung stehen. Beide Dokumentationen werden in englicher Sprache
geschrieben.
3.8 Akzeptanzkriterien
DIONE gilt als akzeptiert, wenn die funktionalen sowie nicht-funktionalen
Anforderungen erfüllt sind. Insbesondere soll der Benutzer, geleitet durch
eine eindeutige Benutzerführung, Data-Mining Prozesse starten und deren
Ergebnisse in für ihn verständlicher Form präsentiert bekommen können.
Die Akzeptanz wird per Abnahmetest geprüft.
151
Kapitel 3 Anforderungsdefinition
152
Kapitel 4
Grobentwurf
4.1 Systemaufbau
Einen Überblick über das System liefert Abbildung 4.1. Die einzelnen Module
und ihre Kommunikation untereinander werden im Folgenden beschrieben.
HTTP
Request
HTTP
Response
Web-Browser
Tomcat
Container
Java-ServerPages
Struts
JobServlets Manager
SQL
Request
Datenstrukturen
SQL
Response
Data-Access-Objects
Dione
Datenbank
Datamining
Algorithmen
Xelopes
Steuerung
SQL
Präsentation
LEDA
Datenbank
Abbildung 4.1: Systemüberblick der einzelnen Modulen
153
Kapitel 4 Grobentwurf
4.1.1 Modul Steuerung
Das Modul Steuerung übernimmt die Ablaufsteuerung der Anwendung. Es
ist in zwei Kernkomponenten aufgeteilt: Für den Kontrollfluss des Programms
aus Sicht des Anwenders sind Struts-Servlets verantwortlich. Sie nehmen den
HTTP-Request entgegen und entscheiden in Abhängigkeit von diesem und
dem aktuellen Systemzustand, welche Webseite mit welchem Inhalt als nächstes Dargestellt wird. Die zweite Komponente stellt der Job-Manager dar. Er
ist der Scheduler für die laufenden DataMining-Prozesse und läuft in einer
einzigen Instanz in einem unabhängigem Thread parallel zu den von dem
Benutzer vorgenommenen Interaktionen.
Struts Servlets
Das Struts-Controller-Servlet hat die Aufgabe, die HTTP-Reqeuests vom
Client entgegenzunehmen. Zu dem muss es entscheiden, welche Funktionen
der anderen Servlets auszuführen sind, und dann die Verantwortlichkeit für
das Erzeugen der nächsten Sicht der Benutzungsschnittstelle an eine passende Java-Server-Page zu deligieren. Die Konfiguration des Controller-Servlets
geschieht mit Hilfe einer XML-Datei (struts-config.xml), die das Verhalten
des Servlets beschreibt. Die bereits erfwähnten weiteren Servlets übernehmen
dann die eigentlichen für den Programmverlauf notwendingen Funktionen wie
z.B. Anfragen an das Datenstrukturen-Modul.
Jobmanager
Der Jobmanager ist eine autome Komponente, die in einer einzigen Instanz
und einem eigenen Thread während der gesamten Laufzeit der Anwendung
zur Verfügung steht. Sie hat die Aufgabe, DataMining-Jobs anzunehmen
und unabhängig von der Benutzerpräsenz durchzuführen und die Ergebnisse in die Datenbank zu schreiben. Eine detaillierte Beschreibung des JobManagers erfolgt in Abschnitt ??. Abbildung 4.2 zeigt die Schnittstelle des
Jobmanagements zur Anwendungsschicht. Jede Aufgabe, deren Ausführung
über das Jobmanagement geregelt werden soll, muss daerInterface MiningJob
implementieren. Anstehende Aufgaben werden mit addJob() hinzugefügt
und können per removeJob() wieder entfernt werden. Eine Liste der abzuarbeitenden Aufgaben kann mit getJobList oder benutzerbezogen mit
getUserJobList() erfragt werden.
Diese Schnittstelle wird als Singleton implementiert. Damit ist gewährleistet, dass genau ein Jobmanager zu einem Zeitpunkt aktiv ist. Desweiteren
154
4.1 Systemaufbau
kann an einer zentralen Stelle (Methode getInstance()) gesteuert werden,
welche Implementation des Jobmanagments genutzt werden soll. Die Teile
der DIONE-Workbench, die den Jobmanager nutzen, sollen nicht angepasst
werden müssen, wenn eine neue Implementation genutzt werden soll.
util
MiningJobManager
+ addJob(job:MiningJob)
+ removeJob(job:MiningJob)
+ getJobList(): List
+ getUserJobList(user:User): List
+ getInstance(): MiningJobManager
MiningJob
+ startJob()
+ pauseJob()
+ stopJob()
+ getUser(): User
+ getStatus(): int
Abbildung 4.2: Schnittstelle zum Jobmanagement
4.1.2 Modul WebUserInterface
Seitenaufbau
Alle Internetseiten sind in vier Bereiche aufgeteilt: Kopf-, Menü-, Arbeitsund Fußbereich. Die Bereiche werden mit Hilfe von HTML-Frames generiert. Auf Frames wird zusätzlich in einigen Darstellungen im Arbeitsbereich
zurückgegriffen.
Im Kopfbereich befindet sich eine Anzeige über den Status der vorhandenen
Experimente (Job-Status). Dabei wird visuell dargestellt, wieviele Experimente noch nicht abgeschlossen sind oder fertig berechnet wurden. Diese
Anzeige erhält ihre Informationen von dem Jobmanager und wird bei jedem
Laden einer Seite aktualisiert. Zur zusätzlichen Navigation werden bei Arbeitsabläufen Register (Reiter, Laschen) eingeblendet. Bei der Durchführung
eines Experimentes werden beispielsweise die Register ”Trait-Matrix”, ”Konfiguration” und ”Ergebnis” (ggf. noch weitere) eingeblendet.
Der Menübereich befindet sich am unterhalb des Kopfbereiches und links neben dem Arbeitsbereich. Der Anwender kann hier alle zur Verfügung stehenden Funktionalitäten erreichen (kontextsensitiv). Sprünge, die im Arbeitsablauf sinnlos bzw. zu Fehlern führen könnten, werden nicht angezeigt. So
155
Kapitel 4 Grobentwurf
Logobereich
Job-Status
Register
Navigation
Arbeitsbereich
Zurück
Weiter
Fußzeile
Schiebebalken
Abbildung 4.3: Grobentwurf der Seitengestaltung
kann beispielsweise der Anwender nicht zu einem Ergebnis gelangen, das
noch nicht existiert. Weitere Details erfolgen im Kapitel ”Navigation”.
Der Arbeitsbereich gibt den jeweiligen eigentlichen Seiteninhalt wieder. Jedoch werden auch hier Navigationselemente eingesetzt. So beinhaltet der Arbeitsablauf die Funktionalität der Fortführung und des Zurückgehens. Diese
Befehle werden durch die Schaltflächen ”Weiter” und ”Zurück” realisiert.
Die Schaltflächen werden am Seitenanfang und am Seitenende angezeigt. Ist
der Seiteninhalt größer als der darstellbare Bereich, werden Schiebebalken
eingeblendet.
Die Fußzeile enthält einen Copyright-Hinweis, einen Link zum Impressum
und ggf. weitere sekundäre Informationen.
Navigation
Grundsätzlich soll der Anwender in der lange sein, auf unterschiedlichen Wegen zu seinem Ziel zu gelangen. Daher werden auch die Navigationselemente
redundant angeboten. Neben der hauptsächlichen Navigationsmöglichkeit im
Menübereich, werden Register im Kopfbereich und Schaltflächen im Arbeitsbereich eingebettet.
Im Navigationsmenü werden in Abhängigkeit der aktuellen Seite im Arbeits-
156
4.1 Systemaufbau
bereich, mögliche Navigationsschritte eingeblendet. Diese ergeben sich logisch aus dem aktuellen Arbeitsschritt.
Sprache
Alle Internetseiten werden in deutscher und englischer Sprache ausgegeben. Die Möglichkeit zur Erweiterung für andere Sprachen wird durch das
Resource-Bundle- Prinzip ermöglich: Alle textuellen Elemente verweisen durch
Labels auf einen Text in der jeweiligen Sprachendatei (z.B. ”Dionede.properties”).
Für jede Sprache gibt es eine Datei. Desweiteren existiert eine DefaultSprachendatei.
Kontrollfluss
Die Darstellung des Inhalt einer Seite wird durch eine JSP-Seite realisiert,
während der Übergang mit Hilfe von Servlets realisiert wird. Desweiteren
wird Struts verwendet. Globale Variablen werden in der Session, die vom
Tomcat-Server erstellt und verwaltet wird gespeichert. Die wesentlichen Daten werden bei den Seitenübergängen an die Datenschicht übergeben. Zu
den globalen Variablen gehört zum Beispiel die Information, auf welcher Seite sich der Anwender momentan befindet.
Nach Aufruf der Indexseite gelangt der Anwender zu einem Login. Hier wird
er aufgefordert, einen Benutzernamen und ein dazu gültiges Kennwort einzugeben. Nach erfolgreicher Eingabe wird eine neue Session vom Tomcat-Server
gestartet. Anschließend erfolgt eine Übersicht im Arbeitsbereich. Hier werden Informationen zu den Experimenten und vorhandenen Verfahren dargestellt. Der anschließende Arbeitsablauf (z.B. Modellerstellung) wird durch
die Verkettung der jeweiligen JSP-Seiten erfolgen und wird kontrolliert von
den Servlets, die sich anhand des Formularinhaltes und des in der Session
gespeicherten Status orientieren. Bei der Erstellung der Trait-Matrix wird
eine Kollision der Upload-Datei mit der über die Weboberfläche zusammengestellte Matrix vermieden.
4.1.3 Modul Datamining Algorithmen
Datenstrukturen von Xelopes
Durch die Verwendung des Datamingpaketes von Xelopes, als Algorithmenunterbau in der DIONE Workbench, wird ein Teil der vordefinierten Ein-
157
Kapitel 4 Grobentwurf
und Ausgabestrukturen übernommen. Die Abbildung 4.4 zeigt eine Auswahl
der Klassen von Xelopes, die in der Entwicklung berücksichtigt werden. Dabei sind die relevantesten farblich hervorgehoben und sollen im folgenden
erläutert werden:
• Als Eingabeobjekttyp dient der MiningInputStream, wobei von ihm
spezifische Eingabearten abgeleitet werden. Anwendung wird hauptsächlich MiningArrayStream finden. Andere Eingaben aus ARFF- oder
CSV-Dateien sind möglich.
• Für jedes Verfahren werden die Konfigurationseinstellungen durch von
MiningSettings abgeleiteten Klassen erzeugt. Diese Klassen benötigen jeweils ein Objekt vom Typ MiningAlgorithmSpecification um
die Grundeinstellungen wie Art der Parameter und Standardwerte für
ein Verfahren zu erhalten.
• Das Verfahren selber wird in einer von MiningModel abgeleiteten verfahrensspezifischen Klassen instanziert. Um das Modell dann erstellen
zu können, benötigen diese Klassen die verfahrensspezifische Klasse von
MiningSettings und ein Objekt vom Typ MiningInputStream.
Die Schnittstelle zur Xelopes-Bibliothek
Um die DIONE-Workbench von der Entwicklung der Xelopes-Bibleothek
weitestgehens unabhängig zu halten, wird die Auswahl und Konfiguration
der Algorithmen aus externer Quelle, der DIONE-Datenbank, erzeugt.
Die Abbildung 4.5 zeigt die Schnittstelle zu Xelopes:
• Die AlgorithmFactory realisiert die Verfahrensbeschreibung der Algorithmen. Dabei gibt sie Auskunft in Form von Listen über ihre Verfahren und die zugehörigen Parameter.Des weiteren gibt sie Datamining(MiningAlgorithm) und Attributtransformations-Algorithmusobjekte
(TransformationMethod) bei Übergabe einer Algoritmusid zurück.
• Als Ergebnis dient MiningResult, in der die Methoden für textuelle
und grafische Ausgaben definiert werden. Zudem soll eine Liste der
Exportformate erzeugbar sein. Für die Ergebnistypen Modellerstellung,
Voraussage und Verifikation sind einzelne Ergebnisimplementierungen
von MiningResult vorgesehen.
158
4.1 Systemaufbau
Xelopes
MiningArffStream
MiningFileStream
MiningCsvStream
<<interface>>
(from Xelopes)
(from Xelopes)
(from Xelopes)
MiningTransformer
(from Xelopes)
benutzt
MiningArrayStream
MiningInputStream
MiningFilterStream
(from Xelopes)
(from Xelopes)
(from Xelopes)
MultipleToMultipleMapping
(from Xelopes)
benutzt
VectorTransformationStream
(from Xelopes)
ReplaceMissingValueStream
(from Xelopes)
RemoveAttribute / AddAttribute
benötigt
(from Xelopes)
MiningModel
(from Xelopes)
(from Xelopes)
ClusteringMiningModel
(from Xelopes)
(from Xelopes)
benötigt
AssociationRulesMiningModel
ChangeAttributeOrder
ClassificationMiningModel
MiningSettings
(from Xelopes)
(from Xelopes)
ClusteringSettings
AssociationRulesSettings
(from Xelopes)
benötigt
(from Xelopes)
MiningAlgorithmSpecification
(from Xelopes)
DecisionTreeSettings
(from Xelopes)
Abbildung 4.4: Schnittstelle zu Xelopes
• Für den interaktiven Entscheidungbaumalgorithmus ist ein Eingabe in
Form eines nächsten auszuführenden Schritts und eine Ergebnisausgabe des Zwischenschritts vorgesehen.
Interaktiver Entscheidungsbaumalgorithmus
Als eine Datamingmethode soll ein interaktiver Entscheidungsbaum implementiert werden. Hierbei soll es dem Benutzer möglich sein, interaktiv bei
der Erstellung des Modells einzugreifen. Dabei hat der Benutzer folgende
Möglichkeiten:
• Bei jedem Knoten kann der Benutzer das zu splittende Attribut wählen.
Hierbei kann der Benutzer das Attribut manuell auswählen oder aber
automatisch das beste Attribut bestimmen lassen
• Bei jedem Endknoten wird der Informationsgehalt eines jeden Attributes angezeigt. Dieses dient zur Hilfestellung beim Splitting
• Der Benutzer kann die Splitting-Aktionen in umgekehrter Reihenfolge
rückgängig machen (Prunen), bis zur Wurzel des Baumes
159
Kapitel 4 Grobentwurf
algorithm
AlgorithmFactory
+ getDataMiningMethodList(): List
+ getDataMiningMethodParameterList(method:DataMiningMethod): List
+ getTransformationMethodList(): List
+ getTransformationMethodParameterList(method:TransformationMethod):
List
+ getInstance(): AlgorithmFactory
MiningResult
MiningModelBuildResult
+ getStatus(): int
+ getComponent(): Component
+ getText(): String
+ getExportFormats(): List
InteractiveNextStep
MiningInteractiveStepResult
MiningPredictionResult
MiningVerificationResult
Abbildung 4.5: Schnittstellen WebUserInterface - Algorithmen
• Bei der Implementierung wird von den Xelopes-Klassen für Entscheidungsbäume abgeleitet.
Der Austausch der Daten mit dem WebUserInterface findet über die Interfaces MiningInteraktiveStepResult, für die Ausgabe, und
InteractiveNextStep, für die Eingabe des Algorithmus, statt. Diese Interfaces finden sich in Abbildung 4.5 wieder. Die Hauptklasse des Algorithmus
befindet sich im Unterpaket model des Paketes algorithms, wie in Abbildung 4.6 zu erkennen ist.
model
InteractiveDecisionTree
Abbildung 4.6: Klasse des interaktiven Entscheidungsbaumalgorithmus
160
4.1 Systemaufbau
4.1.4 Modul Datenstrukturen
Datenstrukturen
TraitMatrix
• wird aus Species (“Zeilen”) und Traits bzw. deren Attributen (“Spalten”) zusammengesetzt
• kann ein MiningInputStream für Xelopes erzeugen, sodass dieses seine
Algorithmen direkt auf der Struktur ausführen kann
• Species und Traits sollen auch explizit hinzugefügt werden können (z.B.
für CSV-Import von Daten).
Datenbankzugriff
Zugriff auf die Datenbank per DAO Data Access Objekte (DAOs) abstrahieren und kapseln die Daten der Datenbank. DAOs managen und kontrollieren ferner die Verbindung zur Datenbank. Sie ermöglichen eine persistente
Datenhaltung und die Verwendung verschiedener DBMS. Wie der Abbildung 4.1.4 zu entnehmen ist, nimmt das DAO eine vermittelende Rolle. Es
stellt dem BusinessObjekt (z.B. UserInterface) über das TransferObject die
Daten der Datenbank zur Verfügung. Dieses wird über Methoden des DAOs
gefüllt bzw. zum Speichern/Modifizieren von Daten in der Datenbank vom
DAO verwendet. Transferobjekte lassen sich meist sehr einfach als JavaBeans
erstellen, sodass andere Komponenten leicht auf die Daten zugreifen können.
Es ist ausserdem möglich, in einem DAO die Daten aus mehreren Tabellen
abzufragen bzw. wieder auf diese zu verteilen.
Abbildung 4.7: DAO-Schema
161
Kapitel 4 Grobentwurf
Ein Erweiterung des Schemas durch eine DAO Factory erhöht die Flexibiltät und Kompatiblität. So ist es einfach möglich verschiede Datenbankarte (ORDBMS, OODBMS usw.) oder auch Verzeichnisdienste (JNDI, LDAP
usw.) zu benutzen, da für jede Art ein DAO-Unterart angelegt werden kann.
Dieses ermöglicht auch verscheidene Datenbanken unterschiedlicher Hersteller zuverwenden. Auch Caching - Strategien lassen sich somit verwirklichen,
ohne dass der Code der Applikation umgeschrieben werden muss.
Abbildung 4.8: DAO-Factory 1
DioneUserDAO
• wird Benutzerverwaltung beinhalten, also auch Hinzufügen von Experimenten, Traitmatrizen und Konfigurationen (public/private) für einen
Benutzer.
• Abfrage von Experimenten, Traitmatrizen, Konfigurationen, Ergebnissen eines Benutzers
• Integration mit existierenden LEDA-Benutzern (LEDA-Schema)
• Integration in Tomcat und Struts per JAAS, FormBased Authentication, BasicAuth o.ä.
• Möglichkeit Data-Mining Jobs zu verwalten
162
4.1 Systemaufbau
Abbildung 4.9: DAO-Factory 2
ConfigDAO
• Speichern/Auslesen von Konfigurationen (Modell, Modellverifizierung,
Vorhersage, Nullwertbehandlung)
TraitMatrixDAO
• Speichern/Auslesen einer kompletten Traitmatrix
ResultDAO
• Speichern/Auslesen von Ergebnissen
ExperimentDAO
• Speichern/Auslesen eines kompletten oder teilweisen Experimentes
163
Kapitel 4 Grobentwurf
Hochladen von Artenlisten
• CSV- File kann vom Benutzerrechner hochgeladen werden und bildet
initiale Traitmatrix
• Weitere Daten enthalten Werte; können nach dem Hochladen konfiguriert werden ebenso wie Einteilung in Numerische, Ordinale und Aggregierte
• Hochladen von weiteren Attributen und Pflanzen erlaubt
4.1.5 Schnittstelle User - WebUserInterface
Die Interaktion mit dem Benutzer erfolgt über den Webbrowser. Alle Aktionen können über Schaltflächen vorgenommen werden, die in den jeweiligen
Kontext von den HTML-Seiten zur Verfügung gestellt werden. Erforderliche
Daten werden nach Möglichkeit durch eine Auswahl von bestehenden Daten
abgefragt. Dazu werden bevorzugt HTML-Comboboxen verwendet. Individuelle Dateneingaben erfolgen durch Textfelder und werden nach Zurücksenden
des Formulares an den Server geprüft. Sofern der Platz im Arbeitsbreich ausreicht, sollen Erkärungen über Funktionalitäten (bzw. erforderliche Daten)
direkt angezeigt werden. Weitere Hilfe wird durch eine Schaltfläche im Navigationsmenü zugänglich. Auf die Verwendung von Symbolen soll größtenteils
verzichtet werden, sofern sie nicht einem allgemeinen Standard entsprechen.
4.1.6 Schnittstelle WebUserInterface - Datenstrukturen
Benutzer:
Methode
Benutzer einloggen
Benutzer ausloggen
Benutzerdetails modifizieren
Anfrage der vorhandenen Ergebnisse
Parameter
Benutzername, Passwort
Benutzerobjekt
Benutzerobjekt
Rückgabe
Benutzerobjekt
Benutzerobjekt
Liste der Ergebnisse zu
abgeschlossenen Data
Mining-Prozessen
wird fortgesetzt auf nächster Seite
164
4.1 Systemaufbau
fortgesetzt von vorheriger Seite
Methode
Parameter
Rückgabe
Tabelle 4.1: Methoden von Benutzer
Traitmatrix:
Methode
Liste der gespeicherten Traitmatrizen anfordern
Gespeicherte Traitmatrix laden
Parameter
Benutzer
gewünschte
Matrix,
Maximale Anzahl der
Zeilen, Start- und
letzte Zeile
Traitmatrix Traitmatrix
Aktuelle
speichern
Allgemeine Bearbeitungsoperationen
je nach dem
Rückgabe
Liste der vorhandenen
Matrizen
Aktuelle Traitmatrix
in gewünschter Maximalgröße, Tatsächliche
Größe der Traitmatrix
je nach dem
Tabelle 4.2: Methoden der Traitmatrix
Modellerstellung:
Methode
Speichern der Konfiguration
(Modellerstellung)
Parameter
Rückgabe
Algorithmus / Parameter / Traitmatrix /
Ergebnis, Name, Benutzer
Anfordern einer Lis- Benutzer
Liste der gespeicherten
te von gespeicherten
Konfigurationen
Konfigurationen (Modellerstellung)
Laden einer Konfigu- Name
Algorithmus / Pararation (Modellerstelmeter / Traitmatrix
lung)
wird fortgesetzt auf nächster Seite
165
Kapitel 4 Grobentwurf
fortgesetzt von vorheriger Seite
Methode
Parameter
Rückgabe
Tabelle 4.3: Methoden für Modellerstellung
Modellverifizierung:
Methode
Liste der verfügbaren
Algorithmen zur Modellverifizierung anfordern
Liste der verfügbaren
Parameter zu einem
Algorithmus anfordern
Speichern der Konfiguration (Modellverifizierung)
Parameter
Algorithmusobjekt
Rückgabe
Liste der verfügbaren
Algorithmen zur Modellverifizierung
Liste der verfügbaren
Parameter zum Algorithmus
Algorithmus / Parameter / Traitmatrix /
Ergebnis, Name, Benutzer
Anfordern einer Lis- Benutzer
Liste der gespeicherten
te von gespeicherten
Konfigurationen
Konfigurationen (Modellverifizierung)
Laden einer Konfigu- Name
Algorithmus / Pararation (Modellverifiziemeter / Traitmatrix
rung)
Tabelle 4.4: Methoden für Modellverifizierung
Vorhersage:
Methode
Speichern der Konfiguration (Vorhersage)
Parameter
Algorithmus / Parameter / Traitmatrix /
Ergebnis, Name, Benutzer
Rückgabe
wird fortgesetzt auf nächster Seite
166
4.1 Systemaufbau
fortgesetzt von vorheriger Seite
Methode
Parameter
Anfordern einer Lis- Benutzer
te von gespeicherten
Konfigurationen (Vorhersage)
Laden einer Konfigura- Name
tion (Vorhersage)
Rückgabe
Liste der gespeicherten
Konfigurationen
Algorithmus / Parameter / Traitmatrix
(Pflanze)
Tabelle 4.5: Methoden für Vorhersage
Ergebnisbehandlung:
Methode
Anfordern der möglichen Export- bzw. Reportformate]
Exportieren von Ergebnissen
Parameter
Konfiguration
Konfiguration,
portformat
Ex-
öffentlich machen (für Konfiguration, Benutalle Speichern) von Ex- zer
perimenten (Ergebnissen)
Anfordern einer Liste
der öffentlichen Konfigurationen
Rückgabe
Liste der verfügbaren
Export-/Reportformate
Ergebnis im Exportformat bzw. Ergebnisreport
Liste der öffentlich gemachten Konfigurationen
Tabelle 4.6: Methoden der Ergebnisbehandlung
• Benutzerverwaltung
LedaUser sind mit DioneUser verknuepft
Traitmatrix, Konfigurationen und Ergebnisse koennen geladen, gespeichert und veroeffentlicht werden
• CSV Dateiimport als initiale Traitmatrix
• Funktionen zur Auswahl/Hinzufuegen/Entfernen von Traits
• Datenstruktur zum Halten und Abfragen (fuer Anzeige) der fertigen
Ergebnisse
167
Kapitel 4 Grobentwurf
4.1.7 Schnittstelle WebUserInterface - Algorithmen
Modellerstellung:
Methode
Liste der verfügbaren
Algorithmen
zur Modellerstellung
anfordern
Liste der verfügbaren
Parameter zu einem
Algorithmus anfordern
Setzen der Ausprägung
des Parameters eines
Algorithmus zur Modellerstllung
Anstoßen des Modellerstellungs-DataMining-Prozesses
Abfrage
des
Ergebnis
eines
ModellerstellungsDataMining-Prozesses
Parameter
Algorithmusobjekt
Rückgabe
Liste der verfügbaren
Algorithmen zur Modellerstellung
Liste der verfügbaren
Parameter zum Algorithmus
Ausprägung des Parameters
Konfiguration
Abschätzung der Dauer
Konfiguration
Ergebnisobjekt
dell)
(Mo-
Tabelle 4.7: Methoden für Modellerstellung
Modellverifizierung:
Methode
Parameter
Setzen der Ausprägung Ausprägung des Parades Parameters eines meters
Algorithmus zur Modellverifizierung
Anfordern einer Lis- Benutzer
te von gespeicherten
Konfigurationen (Modellverifizierung)
Rückgabe
Liste der gespeicherten
Konfigurationen
wird fortgesetzt auf nächster Seite
168
4.1 Systemaufbau
fortgesetzt von vorheriger Seite
Methode
Anstoßen
des
ModellverifizierungsDataMining-Prozesses
Abfrage
des
Ergebnis
eines
ModellverifizierungDataMining-Prozesses
Parameter
Konfiguration
Rückgabe
Abschätzung der Dauer
Konfiguration
Ergebnisobjekt (Verifizierung)
Tabelle 4.8: Methoden für Modellverifizierung
Vorhersage:
Methode
Liste der verfügbaren
Algorithmen zur Vorhersage anfordern
Liste der verfügbaren
Parameter zu einem
Algorithmus anfordern
Setzen der Ausprägung
des Parameters eines
Algorithmus zur Vorhersage
Anstoßen
des
VorhersagungsDataMining-Prozesses
Abfrage des Ergebnis
eines VorhersagungsDataMining-Prozesses
Parameter
Algorithmusobjekt
Rückgabe
Liste der verfügbaren
Algorithmen zur Vorhersage
Liste der verfügbaren
Parameter zum Algorithmus
Ausprägung des Parameters
Konfiguration
Abschätzung der Dauer
Konfiguration
Ergebnisobjekt
hersage)
(Vor-
Tabelle 4.9: Methoden für Vorhersage
Interaktion:
Methode
Abfragen
eines
DataMining-Schrittes
(interaktiv / Modellerstellung)
Parameter
Rückgabe
Algorithmus / Para- Ergebnisobjekt (intermeter / Traitmatrix, aktiv)
Name, Benutzer
wird fortgesetzt auf nächster Seite
169
Kapitel 4 Grobentwurf
fortgesetzt von vorheriger Seite
Methode
Parameter
Rückgängig machen / Konfiguration
Wiederherstellen des
letzten
interaktiven
DataMining-Schrittes
Rückgabe
Ergebnisobjekt (interaktiv)
Tabelle 4.10: Methoden für Interaktion
Jobhandling:
Methode
Anfordern der laufenden Tasks
Anfordern der laufenden öffentlichen Tasks
Hinzufügen
eines
Tasks
Anhalten und Entfernen eines Tasks
Feststellen, ob ein
Task erfolgreich beendet worden ist
Parameter
Userobjekt
Rückgabe
Liste der laufenden
Tasks
Liste der laufenden
öffentlichen Tasks
Task
Task
Task
Feststellung, ob ein
Task erfolgreich beendet worden ist
Tabelle 4.11: Methoden für Jobhandling
4.1.8 Schnittstelle Algorithmen - Datenstrukturen
• Aus einem Experiment kann die Traitmatrix in einen MiningInputStream überführt werden. Aufgrunddessen liegt sie in direkt für Xelopes weiterverarbeitender Weise vor.
• Parameter werden aus der Datenbank oder von der Benutzereingabe in
Datenstrukturen gespeichert und an die Algorithmen weitergegeben.
• Ergebnisobjekte/Konfigurationen koennen in Dione Datenbank abgelegt werden.
170
4.1 Systemaufbau
4.1.9 Kommunikation Steuerung - Algorithmen
Bezeichnung
Vorbedingung
Starten eines Datamining Algorithmus
Fehler werden vorher abgefangen, somit dürfen die Daten als korrekt angenommen werden. Es liegen eine Dataminingmethode und ihre gewählten Parameter vor.
Nachbedingung Resultat ist in Experiment-Objekt gespeichert
Beschreibung
Das Datamining-Verfahren wird mit den vorliegenden
Experimentdaten und der Konfiguration ausgeführt
Fehler
MiningException, OutOfMemory
Bezeichnung
Starten einer Transformationsmethode
Vorbedingung
Traitmatrix und Eingaben liegen vor.
Nachbedingung Traitmatrix enthält die modifizierten Daten.
Beschreibung
Die Traitmatrix wird nach dem gewählten Transformationsverfahren bearbeitet. Die Werte werden durch die
Eingabendaten ersetzt.
Fehler
TransformationsException, OutOfMemory
4.1.10 Kommunikation Steuerung - Datenstrukturen
Alle Daten die aus der Datenbank für die Steuerung benötigt werden, werden
als DAOs übergeben.
Bezeichnung:
Datenspeicherung
Vorbedingung:
Dateneingaben des Nutzers wurden zuvor überprüft.
Nachbedingung: Daten sind gespeichert.
Beschreibung:
Daten werden als DAO-Objekte von die Datenstrukturschicht weitergeleitet. Sollte ein Speicherung nicht erfolgt sein (z.B. bei einem Verbindungsfehler), wird eine
Fehlermeldung zurückgegeben.
Fehler:
Write-Error
Bezeichnung:
Vorbedingung:
Nachbedingung:
Beschreibung:
Fehler:
Trait-Matrix holen
Experiment-Objekt ist vorhanden.
Matrix kann vom Servlet in die JSP-Seite überführt werden.
für die Anzeige auf der JSP-Seite wird die Trait-Matrix
als DAO Experiment.getTraitMatrix() vom Servlet zur
Verfügung gestellt.
Read-Error
171
Kapitel 4 Grobentwurf
Bezeichnung:
Vorbedingung:
Nachbedingung:
Beschreibung:
Fehler:
Bezeichnung:
Vorbedingung:
Nachbedingung:
Beschreibung:
Fehler:
Bezeichnung:
Vorbedingung:
Nachbedingung:
Beschreibung:
Fehler:
Algorithmenübersicht
Algorithmenliste ist vorhanden.
Algorithmenliste kann vom Servlet in die JSP-Seite
überführt werden.
Zur Auswahl des gewünschten Verfahrens wird eine Liste der verfügbaren Algorithmen als DA-Objekt übergeben.
Read-Error
Konfiguration
Daten für die Konfiguration sind vorhanden.
Konfiguration kann vom Servlet in die JSP-Seite
überführt werden.
Zur Konfiguration des Verfahrens wird ein DA-Objekt
übergeben, das Namen, Datenformate, Standardwerte
und Wertebereiche enthält.
Read-Error
Ergebnisausgabe
Ergebnis ist vorhanden.
Ergebnis kann über Servlet angezeigt werden.
Das Ergebnis wird mit getMiningResult() aus dem DAO
Experiment ausgelesen und dargestellt.
Read-Error
4.1.11 Kommunikation Steuerung - Präsentation
Bezeichnung:
Vorbedingung:
Datentransfer des Arbeitsbereiches
Mögliche Dateneingaben werden an das Servlet weitergereicht und Seitenwechsel wird vom Benutzer ausgelöst.
Nachbedingung: Seitenwechsel und Datenübergabe
Beschreibung:
Es erfolgt eine Speicherung der Daten. Nächste JSPSeite wird angezeigt. Bei Eingabefehlern wird das entsprechende Feld markiert und ein zusätzliche Erklärung
in Form einer Zusatzhilfe ausgegeben.
Fehler:
Inputerror
172
4.2 Ablaufbeschreibung
Bezeichnung:
Aktualisierung des Jobmanagers
Vorbedingung:
Seitenwechsel wird vom Benutzer ausgelöst.
Nachbedingung: Neuer Status der Jobs
Beschreibung:
Bei jedem Seitenwechsel wird der neue Status der Jobs
übergeben.
Fehler:
Read-Error
4.1.12 Kommunikation Datenstrukturen - Algorithmen
Bezeichnung:
Dataminingalgorithmen
Vorbedingung:
Liste über Dataminingalgorithmen ist vorhanden.
Nachbedingung: Algorithmen sind benannt und aufrufbar.
Beschreibung:
Die Liste bestimmt die Algorithmen und ihren Klassenpfad
Fehler:
Read-Error
Bezeichnung:
Vorbedingung:
Dataminingparameter
Liste über Algorithmen und Dataminingparameter ist
vorhanden.
Nachbedingung: Algorithmen können instanziiert werden
Beschreibung:
Die Liste bestimmt die Algorithmen und ihren Klassenpfad
Fehler:
Read-Error
4.2 Ablaufbeschreibung
Der Ablauf der Anwendung ist durch die Navigation der Präsentationsschicht vorgegeben, die von der Steuerungsschicht durch Servlets kontrolliert
wird. Fehlerhafte Eingaben oder Fehler im Ablauf werden von der Steuerung
übernommen. Anders als bei klassischen Anwendungen ist ein Controller in
der Form nicht notwendig. Eine Kommunikation zwischen der Präsenationsschicht und der Algorithmen wird nicht benötigt. Die Präsentationsschicht
empfängt alle Daten aus der Datenschicht. Informationen über den Status
eines Experimentes werden vom Jobmanager übernommen. Bestandteile der
Steuerung sind:
• Bestandteile von Struts (ActionServlet, config.xml, ...)
• Servlets als Bindeglied zwischen den JSP-Seiten
• Jobmanager
173
Kapitel 4 Grobentwurf
Der Ablauf ist abhängig von den drei wesentlichen Anwendungsfällen und
sei nun im folgenden beschrieben:
4.2.1 Anwenderauthentifizierung
Da der Bereich des DIONE-Projektes keine autonome Webapplikation ist,
sondern in ein bestehenden Projekt integriert wird, ist eine eigene Benutzerverwaltung nicht notwendig. Hierbei werden die Tomcat-Realms verwendet
mit Single-Signon, sodass nur eine einzige Anmeldung für alle Anwendungen
nötig ist.
4.2.2 Experimentauswahl
Auf der ersten Seite erhält der Anwender einen Überblick über die vorhandenen eigenen und öffentlichen Experimente. Hier kann er zum Bearbeiten eines
auswählen oder ein neues Experiment anlegen. Möchte er auf ein vorhandenes Experiment zurückgreifen, erhält er einen Überblick über das jeweilige
Experiment. Darin enthalten sind Informationen über den Arbeitsprozess.
Alle Arbeitsschritte können bearbeitet werden. Soll ein neues Experiment
angelegt werden, wird der Anwender aufgefordert, ein Namen für das Experiment zu vergeben. Nun wird ein neues Experiment erzeugt und in der
Datenbank gespeichert.
Mögliche Fehlerquellen: Beim Lesen oder Schreiben von Daten kann es zu
Verbindungsfehler zwischen der Steuerung und der Datenbank kommen. Die Steuerung wartet beim Schreiben von Daten auf eine Bestätigung.
4.2.3 Erstellen einer Trait-Matrix
Mögliche Dateien, die der Anwender von seinem Client auf den Server laden
kann, werden auf ihr korrektes Format geprüft. Zugelassen sind nur Dateien im CSV-Format. Nach dem Hochladen kann eine Änderung der Wertespalten erfolgen. Für die spätere Verwendung der Daten muss bekannt sein,
ob es sich beispielsweise um nummerische oder ordinale Werte handelt. Die
Auswahl von Pflanzen aus der LEDA-Datenbank erfolgt über eine Suchmaske, die eine Suche nach Pflanzennamen und Attributwerten ermöglicht. Die
Ergebnisse der Suchanfragen müssen vom Anwender gruppiert werden. Anschließend gibt es die Möglichkeit, eine Aggregation der Daten vorzunehmen.
174
4.2 Ablaufbeschreibung
Hinzufügen von weiteren Pflanzen erfolgt durch erneute Suchanfragen. In
mehreren Schritten entsteht so eine Trait-Matrix, die nach jedem Teilschritt
gespeichert wird.
Mögliche Fehlerquellen: Eine intensive Prüfung der zu importierten Datei ist notwendig. Sonstige Fehler beruhen auf Verbindungsfehler zur
Datenbank. Die Steuerung erhält lediglich eine Bestätigung.
4.2.4 Auswahl des Verfahrens und Konfiguration
Im nächsten Schritt wird der Anwender aufgefordert, einen Algorithmus auszuwählen und eine Konfiguration vorzunehmen. Fehlerhafte Eingaben werden sofort bei einem Seitenwechsel bearbeitet. Alle Daten werden in die Datenbank gespeichert.
4.2.5 Start des Verfahrens
In diesem Schritt arbeiten zum ersten Mal alle Schichten zusammen. Zunächst
erhält die Steuerungsschicht den Befehl zum Starten des Verfahrens von der
Präsentationsschicht. Sind alle notwendigen Daten vorhanden (Trait-Matrix,
Konfiguration und ggf. Modell) kann das Verfahren gestartet werden. Dazu
erfolgt eine Initialisierung der Algorithmen. Benötigte Daten werden aus der
Datenbank direkt geladen. Der Jobmanager erhält ein neues Objekt, es sei
denn, es handelt sich um einen interaktiven Algorithmus. Ist des Verfahren
beendet, wird das Ergebnis in das Experiment eingetragen und der Jobmanager benachrichtigt. Der Anwender erhält diese Information nach einem
Seitenwechsel.
Mögliche Fehlerquellen: Ein Fehler, der von der Algorithmenschicht behandelt werden muss, ist die überanspruchung des Speicherplatzes oder
der durch Xelopes vordefinierten Ausnahmebehandlungen. In diesen
Fällen muss das Verfahren abgebrochen werden.
4.2.6 Verlauf des Verfahrens
Die Algorithmusschicht bearbeitet das Experiment, aus dem die Traitmatrix,
das Verfahren und die Parameter, gegebenenfalls ein vorgegebenes Modell
ausgelesen wird. Nach dem jeweiligen Verfahren wird ein Ergebnis (Modell,
175
Kapitel 4 Grobentwurf
Vorhersage und Verifikation) erstellt und in das Experiment zurückgeschrieben. Mit geeigneter Grafikdarstellung kann es dem Nutzer angezeigt werden.
für den interaktive Entscheidungsbaumalgorithmus unterscheidet sich der
Vorgang durch die Bereitstellung eines Teilergebisses in Form eines Zwischenschrittresultats (vgl. 4.5). Dieses Ergebnis wird dem Benutzer angezeigt und
Eingabemöglichkeiten offeriert. Nach Auswahl des nächsten Schrittes wird
das Verfahren mit den Einstellungen und dem Teilmodel neu gestartet.
Bei Beendigung eines Verfahrens und der Rückgabe des Ergebnisses wird die
Speicherung angestoßen. Somit liegen alle erzeugten Resultate in Form eines
Experiments in der Datenbank vor.
Seitens des Benutzers kann der interaktiver Entscheidungsbaumalgorithmus
durch Schließen des Browsers zwar unterbrochen, aufgrund des direkten
Rückschreibens in die Datenbank aber nicht gelöscht werden. Ein Weiterarbeiten wird somit ab dem letzten Zwischenresultat ermöglicht.
176
Kapitel 5
Feinentwurf
5.1 Paketstruktur
5.1.1 Struktur des Java-Quelltextes
Die Quellen von DIONE haben die in Abbildung 5.1 gezeigte Paketstruktur.
Das Hauptpaket heißt de.unioldenburg.dione und besteht aus mehreren Unterpaketen. Jedes Modul wird dabei zu einem Unterpaket zusammengefasst.
de.unioldenburg.dione
model
algorithm
model
model
model
data
model
access
model
transform
model
wui
model
action
model
objects
model
util
model
control
model
lang
model
tag
model
visualization
model
util
model
Abbildung 5.1: Paketstruktur des Java-Quelltextes
5.2 Schnittstellen
Um ein hohes Maß an Abstraktion zu erreichen, ist vorgesehen, die Kommunikation zwischen den einzelnen Modulen Datenhaltung, Algorithmen,
Präsentation und Steuerung über Schnittstellen zu kapseln. Die Abbildung
5.2 bietet hierzu eine Übersicht.
177
Kapitel 5 Feinentwurf
dione
MiningJobManager
TraitMatrix
Column
clone(): Object
findColumn(AttributeDescription): int
1 getRow(int): List
getRowCount(): int
removeRow(int)
addJob(MiningJob)
getUserJobList(User): List
getJobList(): List
removeJob(MiningJob)
getInstance():MiningJobManger
AttributeDescription
clone(): Object
getData():List
setData(List)
toArray(): Object[]
*
1
1
1
1
1
*
MiningJob
TransformationMethod
getExperiment(): Experiment
getUser(): User
getStatus(): int
start()
stop()
pause()
continue()
getName(): String
getDescription(): String
getParameters(): List
*
getAttributeType(): int
getExternalName(): String
getInternalName(): String
getShortTableName(): String
getIsAggregationResult(): int
getShortTableName(): String
getUsedForGrouping(): int
getUsedForOrdering(): int
getValueType(): int
setAttributeType(int)
setExternalName(String)
setInternalName(String)
setIsAggregationResult(int)
setShortTableName(String)
setUsedForGrouping(int)
setUsedForOrdering(int)
setValueType(int)
1
*
1
Experiment
1
getName(): String
setName(String)
getDescription(): String
setDescription(String)
startExperiment()
1
Parameter
1
1
*
MiningAlgorithm
1
*
1
getName(): String
getDescription(): String
getFunctionType(): int
getName():String
getParameterList(): List
1
getType(): int
getName(): String
getDescription(): String
getValue(): Object
setValue(Object)
DioneUser
User(String,String)
getUsername(): String
getSurname(): String
getForename(): String
1
setUsername(String)
setSurname(String)
setForename(String)
getEmail(): String
setEmail(String)
MiningResult
1
clone(): Object
getComponent(): java.awt.Component
getExportFormats(): List
ExportFormat
getMimeType(): String
getName(): String
getDescription(): String
getExport(MiningResult): Object
Abbildung 5.2: Schnittstellen zur Kommunikation der einzelnen Module von
DIONE
Die Instanzen-Implementierungen der Interfaces bieten auf die Daten der
Anwendung zur Laufzeit Zugriff. Die Interfaces MiningJobManager“ und
”
MiningJob“ werden von dem Modul Steuerung implementiert. Die die
”
”
”
Datenhaltung betreffenden Interfaces werden von dem Datenstrukturenmodul implementiert. Schließlich werden die die DataMining-Algorithmen betreffenden Interfaces von dem Algorithmenmodul implementiert.
5.2.1 Modul Datenstrukturen
Vom Modul Datenstrukturen werden die Schnittstellen implementiert, welche den Zugriff auf die Daten des Benutzers erlauben. Dazu zählen einerseits
seine persönlichen Daten sowie die von ihm erstellten Experimente. Die Quelle der Daten ist in der Regel die DIONE- oder die LEDA-Datenbank.
User
über das Interface User kann ein Benutzer am System an- und abgemeldet werden. Ferner kapselt es die Informationen über den Benutzer wie den
Namen und die EMailadresse und bietet Zugriff auf die von ihm erstellten
Experimente.
178
5.2 Schnittstellen
• User(String, String): Konstruktor, über den ein neues Benutzerobjekt erzeugt wird. Dieser Vorgang findet beim Login statt, die eigentliche Anmeldung an das System aber erst durch den Aufruf der Methode login(). Die Parameter sind der Alias (login) und das dazugehörige
Passwort.
• getLogin():String: Gibt den Alias des Benutzers zurück.
• setLogin(String): Setzt einen neuen Alias für den Benutzer.
• getName():String: Gibt den Namen des Benutzers zurück.
• getEMail():String: Gibt die EMailadresse des Benutzers zurück.
• setEMail(String): Legt eine neue EMailadresse des Benutzers fest.
• login(): Meldet den Benutzer an das System an.
• logout(): Meldet den Benutzer vom System ab.
• getExperiments(): List: Liefert eine Liste von den zum Benutzer
gehörenden Experimenten als Instanzen des Interfaces Experiment zurück.
• addExperiment(Experiment): Fügt ein Experiment hinzu.
• removeExperiment(Experiment): boolean: Entfernt ein Experiment des Benutzers. Liefert false bei nicht vorhandenem Experiment,
sonst true.
Experiment
Ein Experiment beinhaltet alle Daten, die zu einem in den UseCases beschriebenen DataMining-Experiment gehören. Dazu zählen insbesondere die
TraitMatrix, der Algorithmus (MiningAlgorithm) und ggf. das Ergebnis (MiningResult).
• getName(): String: Gibt den Namen des Experiments zurück.
• setName(String): Legt den Namen des Experiments fest.
• startExperiment(): Wird vom MiningJobManager aufgerufen, um
das Experiment zu starten.
• getTraitMatrix(): TraitMatrix: Liefert - falls vorhanden - das TraitMatrixObjekt des Experiments, sonst null.
179
Kapitel 5 Feinentwurf
• setTraitMatrix(TraitMatrix): Setzt das TraitMatrix-Objekt des Experiments.
• getMiningAlgorithm(): MiningAlgorithm: Liefert den Algorithmus des Experiments inklusive Konfiguration - falls festgelegt, sonst
null.
• setMiningAlgorithm(MiningAlgorithm): Setzt das MiningAlgorithmObjekt des Experiments.
• getMiningResult(): MiningResult: Liefert bei Verfügbarkeit das
Ergebnisobjekt des Experiments, sonst null.
• setMiningResult(MiningResult): Fügt das Ergebnis des Experiments hinzu.
5.2.2 Modul Algorithmen
Das Modul Algorithmen stellt die Schnittstellen bereit, über die ein Algorithmus mit einem Eingabeexperiment gestartet werden kann und eine Resultat
zurückliefert.
MiningAlgorithm
Das Interface MiningAlgorithm definiert die Methoden, mit denen auf einen
Algorithmus von Dione zugegriffen werden kann.
• getName(): String: Gibt den Namen des Experiments zurück.
• getDescription(): String: Gibt eine Beschreibung über den Algorithmus zurück.
• getParameterList(): List: Rückgabe ist eine List mit den vom Algorithmus benötigten Parametern.
• getFunctionType(): int: Liefert den Funktionstyp des Algorithmus
zurück. Diese sind: 1 für Modellerzeugung, 2 für Verifikation, 3 für
Vorhersage und 4 für interaktive Modellerzeugung.
• startAlgorithm(Experiment exp): Mit Übergabe eines Experimentes wird der Algorithmus von der Steuerung ausgeführt.
• getResult(): MiningResult Nach Durchlauf des Algorithmus ist das
Resultat über diese Methode bereitgestellt.
180
5.2 Schnittstellen
MiningResult
Dieses Interface definiert das Ergebnis und seine Zugriffsmethoden für Repräsentation und Export.
• getComponent(): Component: Gibt den Namen des Experiments
zurück.
• getExportFormats(): List: Eine Liste von Exportformaten wird bereitgestellt.
• setResultId(int resultId): Ordnet dem Resultat eine eindeutige Identifikationsnummer zu.
• getResultId(): int: Liefert die Identifikationsnummmer des Resultats, mit der es in der Datenbank gespeichert wird.
ClusteringMiningAlgorithm
Anhand diese Interfaces ist der Ausgabetyp erkennbar. Es handelt sich dabei
um einen Clustering-Algoithmus.
SupervisedMiningAlgorithm
AssociationRulesMiningAlgorithm
DecisionTreeResult
• getMiningModel(): SupervisedMiningModel :
• getRootNode(): DecisionTreeDataNode:
RuleResult
Das RuleResult-Interface beschreibt das Ergebnis eines regelerzeugenden Algorithmus.
• getRules(): String[ ]: Gibt eine Stringarray aller erzeugten Regeln
zurück.
• getRuleSet(): List: Alle Regeln in einer abstrakten List.
181
Kapitel 5 Feinentwurf
• getTotalRowCount(): int: Die Anzahl aller Datensätze.
• getStatsName(): String[ ]: Das Stringarray enthält die Titel der
Anzeigespalten, die für die Leistungsdaten einer Regel bereitgestellt
werden.
Rule
Dieses Interface beschreibt eine von einen Klassifikationsalgorithmus erzeugte Regel.
• getRuleString(): String: Gibt die Regel in Form eines Strings zurück.
• getRowCount(): double: Rückgabewert ist die Anzahl der von dieser
Regel unterstützen Datensatz.
• getIncorrectlyClassifiedRows(): double: Anzahl der falsch klassifizierten Datensätze.
• getStatsStringValues(): String[ ]: Gibt eine Array von Strings zurück
die Leistungsdaten zu der Regel enthalten.
MiningParameter
Der Mining Parameter als Interface repräsentiert die einzugebenden Parameter, mit denen der Algorithmus gestartet wird.
• getName(): String: Gibt den Name des Parameters zurück.
• getAlgorithmSpecParameterId(): int:
• getDescription(): String: Liefert die Beschreibung des Parameters.
• getParameterType(): Class: Gibt die Klasse des Parameters zurück.
Beispielsweise gibt ein DioneStringMiningParameter die Klasse java.lang.String
zurück.
• getValue(): Object: Liefert den Wert des Parameters.
• getStringValue(): String: Stringrepräsentation des Parameters.
• setValue(Object value) Setzt den Wert für den Parameter. Wirft
ggf. Fehler, wenn der Wert nicht zu dem Parametertyp paßt oder wenn
der Wert ausserhalb der für diesen Parameter definierten Grenzen liegt.
182
5.2 Schnittstellen
• getDefaultValue(): Object: Gibt den Standardwert zurück. Entspricht den Initialwert.
• getMinValue(): Obejct: Liefert den zulässigen Minimalwert für den
Parameter.
• getMaxValue(): Object: Maximale Größe, die die Parameter annehmen dürfen.
• isVisible(): boolean: Setzt den Parameter auf nicht sichtbar und
somit nicht editierbar.
• reset(): Setzt den Parameter auf den Standardwert zurück.
183
Kapitel 5 Feinentwurf
5.3 Inhaltlicher Aufbau der Webseiten von
DIONE
In diesem Abschnitt erfolgt eine grobe sprachliche Beschreibung des funktionalem Aufbaus der Webseiten von DIONE.
Login
Abbildung 5.3: DIONE Login-Seite
Begrüßungsseite für nichtangemeldete Benutzer, welche eine Maske für das
Einloggen bereitstellt. Diese besteht aus Textfeldern für Benutzername und
Passwort sowie einer Schaltfläche, um das Einloggen tatsächlich durchzuführen. Bei erfolgreich vorgenommenem Login erreicht der Benutzer seine individuelle Übersichtsseite. Sollte der Login fehlgeschlagen sein, findet sich der
Benutzer wieder auf der Login-Seite wieder.
Alle Seiten, auf denen der Benutzer eingeloggt ist
Jede Seite beinhaltet Navigationskomponenten, welche es dem Benutzer ermöglichen, innerhalb des Workflows zu navigieren. Insbesondere zählen dazu
vor“ und zurück“-Schaltflächen bzw. Links. Schaltflächen und Links wer”
”
den in diesem Abschnitt synonym verwendet, da das endgültige Aussehen
der Webseiten noch nicht bestimmt ist.
Jede Seite beinhaltet einen Arbeits- bzw. Inhaltsbereich, in dem die relevanten inhaltlichen Dinge dargestellt und ggf. modifiziert werden können.
184
5.3 Inhaltlicher Aufbau der Webseiten von DIONE
Abbildung 5.4: überblick über den Aufbau einer typischen DIONE-Webseite.
Abbildung 5.5: Navigationselement der DIONE-Webseite.
Die Beschreibung der folgenden Seiten bezieht sich ab jetzt immer auf den
Arbeits- bzw. Inahltsbereich der Seite, da die anderen Bereich weitestgehend
identisch pro Seite bleiben.
Am Kopf jeder Seite befindet sich eine Titelleiste (vgl. Abbildung 5.6), welche
DIONE identifziert und dem Benutzer das aktuell bearbeitete Experiment
bzw. seinen Standort, wenn er gerade kein Experiment bearbeitet, anzeigt.
Auch bietet die Titelleiste dem Benutzer die möglichkeit, sich auszuloggen.
Eine Hintergrundcollage bringt Dione, die Pflanzenwelt und die Europaflagge
in Einklang.
Ferner enthält die Titelleiste eine Statusbox, in welcher der Status der laufenden Experimente des Benutzers dargestellt werden (mit Direktlinks). Auch
sind Bereiche für eine ggf. einblendbare kontextsensitive Hilfe vorgesehen.
Eine Übersicht zeigt Abbildung 5.4.
185
Kapitel 5 Feinentwurf
Abbildung 5.6: Die Kopfleiste der DIONE-Webapplikation
Abbildung 5.7: Statusbox, die den Status der laufenden eigenen Experimente
zeigt.
Persönliche Übersichtsseite
Es wird der Status der eigenen Experimente angezeigt und die möglichkeit
gegeben, über einen Direktlink zu der Übersichtsseite des jeweiligen Experiments zu gelangen. Desweiteren ist es möglich, auf eine spezielle ExperimteÜbersichtsseite zu gelangen. Auf Wunsch können die öffentlichen nicht eigenen Experimente ebenfalls auf diese Weise dargestellt werden. Weiterhin
werden die von nun an möglichen Arbeitsschritte inklusive Beschreibung angezeigt und für den nächsten Schritt zur Wahl gestellt.
Neues Experiment (DM-Modell) erstellen
Es wird ein Textfeld für die Eingabe des Namens des Experimentes bereitgestellt. Ferner erfolgt eine Übersicht und Auswahl der zur Verfügung stehenden DataMining-Methoden.
Neues Experiment (Modell-Verifikation / Vorhersage(n)) erstellen
Es wird ein Textfeld für die Eingabe des Namens des Experimentes bereitgestellt. Desweiteren erfolgt eine Übersicht und Auswahl aller verfügbaren
Modelle aus eigenen und öffentlichen fremden abgeschlossenen Experimenten.
186
5.3 Inhaltlicher Aufbau der Webseiten von DIONE
Erstellen einer Trait-Matrix
Um die zu analysierenden Inputdaten zu erzeugen, gibt es drei Möglichkeiten:
Import von einer Trait-Matrix mittels LEDA WebQuery, Kopieren von TraitMatrizen aus öffentlichen Experimenten und Hochladen von CSV-Dateien,
die dann in Trait-Matrizen überführt werden.
Import einer Trait-Matrix mit LEDA WebQuery
Es wird ein Link angeboten, über den man zu LEDA WebQuery gelangt.
Dort kann man sich komfortabel mit dem LEDA-Tool eine Trait-Matrix zusammenstellen. Es wird dann eine Möglichkeit geben, per Link von LEDA
WebQuery zurück zu DIONE zu kommmen, mit dem Resultat, dass die in
WebQuery erzeugte Trait-Matrix automatisch in DIONE importiert wird.
Laden einer Trait-Matrix aus der Datenbank
Es wird eine Liste aller Trait-Matrizen eigener Experimente und eine Liste
alle Trait-Matrizen der öffentlichen Experimente angezeigt. über Radiobuttons kann eine Matrix ausgewählt werden. Dazu gibt es die Schaltflächen
Abbrechen“ und Laden“.
”
”
Importieren (Hochladen) einer Trait-Matrix
Hierzu wird ein Textfeld zur Pfadeingabe und eine Schaltfläche Durchsu”
chen“ angeboten, um die lokale Datei zu finden. Mit der Schaltfläche Hoch”
laden“ wird die Matrix hochgeladen und angezeigt. Ferner werden Comboboxen angeboten, mit denen die Anzahl der gleichzeitig auf einer Seite
angezeigten Pflanzen und der gleichzeitig auf einer Seite angezeigten Traits
ausgewählt werden kann. Entsprechend wird die Wahl gelassen, welchen Bereich (horizontal / vertikal) der Matrix angezeigt werden soll. Mit Textfeldern
können die Traits benannt, mit Comboboxen der Typ ausgewählt werden,
und mit Radiobuttons / Comboboxen können die / kann die Pflanzenidentifikationsspalte(n) ausgewählt werden. Schließlich gibt es die Schaltflächen
Abbrechen“ und Importieren“.
”
”
Konfiguration des DataMining-Algorithmus
Es werden die Konfigurationsmöglichkeiten in Abhängigkeit des Algorithmus angeboten (z.B. Wahl des Zieltraits). Anstelle der Schaltfläche Weiter“
”
187
Kapitel 5 Feinentwurf
wird die Schaltfläche Starten“ angeboten. Bei nicht interaktiven Algorith”
men wird man wieder auf die Übersichtsseite navigiert. Bei interaktiven Algorithmen geht es mit den Interaktionsschritten weiter.
Konfiguration des DataMining-Algorithmus
Es werden die Konfigurationsmöglichkeiten in Abhängigkeit des Algorithmus angeboten (z.B. Wahl des Zieltraits). Anstelle der Schaltfläche Weiter“
”
wird die Schaltfläche Starten“ angeboten. Bei nicht interaktiven Algorith”
men wird man wieder auf die Übersichtsseite navigiert. Bei interaktiven Algorithmen geht es mit den Interaktionsschritten weiter.
Ergebnisanzeige für wirklich abgeschlossenen Experimente
Anzeige des Ergebnis in Abhängigkeit des erzeugten Modells. Ggf. angezeigte Graphiken werden in angemessener Größe präsentiert. über Schaltflächen
ist es möglich, zu einer Detaiansicht zu gelangen (groß oder als svg). Es wird
ferner die Möglichkeit gegeben, weitere Ergebnisse von anderen abgeschlossenen eigenen und öffentlichen fremden Experimenten daneben zum Vergleich
anzuzeigen.
Abbildung 5.8: Das Ergebnis eines Clustering Experiment
188
5.3 Inhaltlicher Aufbau der Webseiten von DIONE
Anzeige des Zwischenergebnis eines interaktiven Algorithmus
(Zwischenergebnis)
Es wird der aktuelle Baum dargestellt und ggf. die möglichkeit gegeben,
die Blätter zu konfigurieren. sowie Knoten ein- bzw. auszublenden. Es wird
ferner die möglichkeit gegeben, weitere Ergebnisse von anderen abgeschlossenen eigenen und öffentlichen fremden Experimenten daneben zum Vergleich
anzuzeigen.
Abbildung 5.9: Das Ergebnis eines Entscheidungsbaum Experiment
Übersichtsseite der Experimente
Anzeige aller eigenen Experimente (Schaltfläche zu den Details des Experiments) mit Checkbox für jedes Experiment. Dazu die Schaltflächen Löschen“,
”
Publizieren“ sowie Abbrechen des Experiments“, welche zu dem Abbrechen
”
”
eines laufenden DM-Prozesses führt.
Übersichtsseite der Details eines Experiments
Es werden alle wichtigen Informationen zum Experiment angezeigt. Ferner
gibt es Schaltflächen zum Export des Modells, zum Erstellen eines Reports
und zum Abbrechen eines laufenden Experiments. Von dieser Seite aus ist
es möglich, den Workflow eines Experiments nachzuvollziehen bzw. fortzusetzen.
189
Kapitel 5 Feinentwurf
Abbildung 5.10: Überblick über die öffentlichen Experimente.
Export eines Modells
Auf dieser Seite stehen Links, welche direkt zu Downloads in entsprechendem
Format führen.
190
5.4 Serverseitige Stuktur der Webseiten von DIONE
5.4 Serverseitige Stuktur der Webseiten von
DIONE
Abbildung 5.11 zeigt die vorgesehenen Speicherorte der einzelnen Webseiten auf dem Server. Dabei ist angedacht, dass inhaltlich verwandte Seiten
in den selben Ordnern gespeichert werden. Dies äußert sich konkret darin,
dass alle Webseiten, die nur dann aufgerufen werden können, wenn der Benutzer erfolgreich eingeloggt ist, in dem Ordner jsp“ zusammengefasst sind.
”
öffentliche Seiten mit funktinonalem Bezug zu DIONE sind (z.B. die Seite,
welche die Einlogmaske bereitstellt) im Wurzelverzeichnis abgelegt. Ferner
werden noch die Ordner scripts“ für die Javascripte sowie Images“ für die
”
”
verwendeten Bilder auf den DIONE Webseiten eingerichtet.
Die in Abschnitt 5.3 beschriebenen Webseiten werden jeweils konkret in einer jsp-Datei repräsentiert. Wie bereits erwähnt, liegen die Seiten, die der
Benutzer mit geglücktem Login verwendet, im Ordner “jsp“.
web-root
about.jsp
model
Back.jsp
model
error.jsp
model
imprint.jsp
model
login.jsp
model
LoginFailed.jsp
model
logout.jsp
model
quickstart.jsp
model
images
jsp
ChooseData.jsp
model
ChooseMethod.jsp
model
ChooseVPData.jsp
model
ControlExperiment.jsp
model
ExperimentOverview.jsp
model
NewExperiment.jsp
model
OwnExperiments.jsp
model
PersonalOverview.jsp
model
result
MiningPrediction.jsp
ClusteringResult.jsp
model
CompareResult.jsp
model
ComponentResult.jsp
model
DecisionTreeResult.jsp
model
InteractiveDecisionTreeResult.jsp
model
RuleResult.jsp
model
TreeVerificationResult.jsp
model
PublicExperiments.jsp
model
scripts
ShowResult.jsp
model
Abbildung 5.11: Struktur der Webordners von DIONE
5.4.1 Übersicht JSP, Skript-Funktionen und Styles
Auflistung der JSPs:
191
Kapitel 5 Feinentwurf
Back.jsp Wird bei der Rückkehr aus Webquery aufgerufen und dient dem
einlesen der ausgewählten Daten
LoginFailed.jsp Aufruf im Falle des fehlerhaften Logins
about.jsp Allgemeine Informationen über das Projekt DIONE
error.jsp Allgemeine Fehlerseite
imprint.jsp Impressum von DIONE
index.jsp Startseite
logout.jsp Zum Ausloggen eines Users
quickstarthelp.jsp Hilfeseite mit einer Kurzanleitung
AlgValuePopup.jsp Dient zur erklärung von Algorithmen Parametern
ChooseData.jsp Auswahl von Daten (Webquery, CSV, ...) zur Modellerstellung
ChooseMethod.jsp Auswahl von vorhandenen Methoden
ChooseVPData.jsp Auswahl von Daten (Webquery, CSV, ...) zur Verifikation und Vorhersage
ConfigureMethod.jsp Konfiguration der Algorithmenmethoden
ControlExperiment.jsp Startseite für den Algorithmus mit der erneuten
Anzeige der Konfiguration
ExperimentOverview.jsp Übersichtsseite des Experimentes
HelpPopup.jsp Hilfe-Popup
NewExperiment.jsp Erstellung eines neün Experiments
OwnExperiments.jsp Übersicht der eigenen Experimente
PersonalOverview.jsp Übersicht der persönlichen/eigenen Daten inklusive
der Nachrichten
PublicExperiments.jsp Übersicht der öffenlichen Experimente
ShowResult.jsp Hauptseite der Ergebnisanzeige mit Einbindung der jeweiligen Ergebnisseiten im Verzeichnis “result“
results/ClusteringResult.jsp Ergebnisanzeige des Clusterings
192
5.4 Serverseitige Stuktur der Webseiten von DIONE
results/CompareResults.jsp Ergebnisvergleich
results/ComponentResult.jsp Ergebnisanzeige
results/DecisionTreeResult.jsp Ergebnisanzeige des Entscheidungsbaumes
results/InteractiveDecisionTreeResult.jsp Ergebnisanzeige des interaktiven
Entscheidungsbaumes
results/MiningPredictionResult.jsp Ergebnisanzeige der Ergebnisvorhersage
results/RuleResult.jsp Ergebnisanzeige der Assoziationsregeln
results/TreeVerificationResult.jsp Ergebnisanzeige der Ergebnisverifikation
results/Subtree.jsp Popup-Fenster des Unterbaumes (Subtree)
Auflistung der Skript-Funktionen von scripts.js:
dialogRUN(form, value, altext, cotext) Funktion für Combobox (ExperimentControl)
dialogPUB(form, value, altext) Funktion für Combobox (öffentliche Experimente)
dialogOWN(form, value, altext, cotext) Funktion für Combobox (eigene
Experimente)
dialogTMA(form, value, altext, cotext) Funktion für Combobox (TraitMatrix)
hide(id) Anzeigen und Verstecken von Objekten
checkAll(check, formNo) Überprüfen aller Checkboxen in einem Formular
checkRadioRow(element, formNo) Überprüfen von Radiobuttons
reverseCheck(formNo) Checkboxselektion rückgängig machen
checkChecks(formNo) Aktualisierung der Checkboxen
hideNavigation(element) Ausblenden der Navigationsleiste
checkRow(element, state) Überprüfen der Zeilenauswahl
Auflistung der Styles:
193
Kapitel 5 Feinentwurf
default.css Styles für Kopfbereich
popup.css Styles für Popup-Fenster
styles.css Styles für alle Elemente
194
5.5 Klassen des WUI Moduls
5.5 Klassen des WUI Moduls
Die Umsetzung des Kontrollflusses über die Webseiten erfolgt mit Hilfe von
Struts (vgl. Abbildung 5.12). Hierzu werden für die wesentlichen Seitenübergänge Servlets definiert, welche von der von Struts bereitgestellten Klasse
Action“ abgeleitet sind. Diese Klasse stellt bereits die für den Kontrollfluss
”
benötigten Methoden bereit, welche von den DIONE-Klassen ggf. überschrieben werden.
Die einzelnen angesprochenen Klassen von DIONE erben jedoch nicht direkt
von “Action“. Es wird noch die Klasse “DioneAction“ zwischengeschaltet,
welche Funktionalität übernimmt, die bei jedem Seitenwechsel in Anspruch
genommen werden soll. Dies ist z.B. das Abrufen des Status der bereits
laufenden Experimente des Benutzers.
wui
model
action
model
tag
model
util
model
tag
model
table
model
Abbildung 5.12: Paketstruktur des Java-Quelltextes
Alle Actions werden in einem Paket gebündelt. Da Dione Multilingual konzipiert wurde, beinhaltet das Paket “lang“ die Sprachdateien (Übersetzungen)
für zunächst zwei Sprachen (Deutsch und Englisch). Im Paket “tag“ werden die Implementationen der Tags realisiert. Sie sorgen für kürzeren und
übersichtlicheren JSP-Code. Da es in der Webanwendung viele Tabellen gibt,
wurde ein Subpaket für die Tabellen erstellt. Das Paket “util“ umfasst alle
Servlets, Beans und kleinere Hilfsklassen.
5.5.1 Paket wui.action
Dieses Paket implementiert die WUI-Actions. Alle Klassen sind abgeleitet
von der DioneAction.java. Alle Actions erhalten Daten aus einem HTMLReqüst bzw. aus einem zuvor ausgefüllten Formular. Die Methode execute wird in allen Actions ausgeführt und endet mit einem Seitenaufruf. Die
Klassen dieses Paketes werden im folgenden in alphabetischer Reihenfolge
erläutert:
195
Kapitel 5 Feinentwurf
ChangeColumnTypeAction Ändert den Spaltentyp der Traitmatrix
ChooseMethodAction Aktion zur Auswahl der Algorithmen-Methode
ChooseModelExperiment Aktion zur Auswahl des Modelltypes
CollapseTreeAction Auf- und Zuklappen aller Knoten beim Explorerbaum
ConfigureMethodAction Aktion für die Konfiguration eines Experimentes
ControlExperimentAction Aktion zum Starten des Algorithmus eines Experimentes
CopyMatrixFromExperiment Kopiert eine Matrix (Hilfsaktion)
CreateDummyMatrixAction Erstellt eine Dummy-Matrix
DioneAction Globale Methoden für alle Actions
EditTableAction Führt Veränderungen an Tabellen aus
ExperimentOverviewChangingAction Führt Veränderungen bei der Experimentenübersicht aus
ExperimentOverviewEditingAction Zum editieren der Experimentenübersicht
LoginAction Aktion zum einloggen eines Users
LogoutAction Aktion zum ausloggen eines Users
NewExperimentAction Erstellt ein neues Experiment
OpenCloseNodeAction Auf- und Zuklappen von Knoten beim Explorerbaum
OpenNodeAction Aufklappen von Knoten beim Explorerbaum
RemoveMatrix Entfernt eine Matrix
SelectExperimentAction Aktion zur Auswahl eines Experimentes
SetFlag Aktion zum Setzen von Markierungen
TableAction Aktionen zum Blättern in Tabellen und Sortieren nach Spalten
TreeAction Markiert den Knoten eines Baumes
196
5.5 Klassen des WUI Moduls
TrueTreeAction Führt gewünschte Aktionen (ausklappen, einklappen von
Ästen) für den ausgewählten Knoten durch. Bei Interaktion wird die
Aktion für Benutzereingaben genutzt
UploadCSVAction Aktion zum Hochladen einer CSV-Datei
5.5.2 Paket wui.lang
Dieses Paket beinhaltet Dateien für die Umsetzung von Labels zu Text in der
jeweiligen Sprache. Da die Webseite mehrsprachig ist, kann hier eine einfach
Umsetzung erfolgen. Die Verwendung dieses Paketes ist näher in den Kapitel
über ausgewählte Abläufe beschrieben.
5.5.3 Paket wui.tag.table
Dieses Paket beinhaltet alle tags, die über Struts verwendet werden und für
Tabellenausgaben erforderlich sind.
ClusteringDescriptionTableUtils Tabelle für Clustering-Beschreibung
ClusteringTableUtils Tabelle für Clustering-Daten
ExperimentTableUtils Tabelle für Experimente
MatrixTableHeaderTag Tabelle für den Kopfbereich einer Matrixtabelle
MatrixTableUtils Tabelle für eine Matrixtabelle
RulesTableUtils Tabelle für Regelausgabe
SimpleTableHeaderItem Kopfbereich einer einfachen Tabelle
TableContentTag Allgemeine Inhaltsbereich aller Tabellen
TableHeaderItem Kopfbereich einer allgemeinen Tabelle
TableHeaderTag Kopfbereich einer allgemeinen Tabelle
TableState Zum Setzen und zur Rückgabe verschiedener Zustände einer
Tabelle
TableTag Stellt den Rahmen für alle Tabellen
TableUtils Beinhaltet Hilfsmethoden für Tabellen
VerificationTableUtils Tabelle für die Darstellung des Ergebnis einer Verifikation
197
Kapitel 5 Feinentwurf
5.5.4 Paket wui.tag.tree
Dieses Paket beinhaltet alle tags, die über Struts verwendet werden und für
Baumdarstellung erforderlich sind.
Tree Implementation der Explorer-Baumdarstellungsfunktionen
TreeTag Ausgabe der Explorer-Baumdarstellung
5.5.5 Paket wui.tag
Dieses Paket beinhaltet alle tags, die über Struts verwendet werden. Für jeden Tag wird die Methode “doStartTag“ verwendet. Sie beinhaltet den auszuführenden Java-Code. Für die folgenden Tag-Klassen soll an dieser Stelle
lediglich eine kurze Beschreibung der Aufgabe erfolgen. Technische Einzelheiten sind der externen Code-Dokumentation zu entnehmen.
AvailableAlgrorithmsTag Zum Anzeigen der verfügbaren Algorithmen.
ConfigurationOverviewTag Zeigt die Übersicht zur Konfiguration an.
ConfigurationTag Anzeige der Konfiguration eines Experimentes
ContentFrameInnerTag Zur Positionierung des Arbeitsbereiches
ContentFrameTag Zur Positionierung des Arbeitsbereiches
ContentTag Umschließt den Inhaltsbereich
ControlExperimentTag Zur Anzeige des Status eines Experimentes mit der
Möglichkeit zum Abbrechen normaler Experimente
DioneTag Basisklasse für alle Tag-Klassen, die das Dione Resource-Bundle
nutzen. Diese Klasse wird abgeleitet von TagSupport
ExperimentOverview Zur Anzeige der Experimentenübersicht
FrameTag Tag für den Beginn eines Frames
GlobalnavigationTag Zur Anzeige der Navigationselemente. Zu dieser Klasse gehören vier weitere Tag-Klassen, die ebenfalls für die Navigation
zuständig sind: “GlobalnavigationitemTag“, “GlobalnavigationsubitemTag“,
“GlobalnavigationsubtitleTag“ und “GlobalnavigationtitleTag“.
198
5.5 Klassen des WUI Moduls
HeaderTag Diese Klasse erzeugt den Kopfbereich von der Internetseite
HelpboxTag Tag für die Anzeige der Hilfetextrahmen
ImageContainerTag Hilfsklasse für die Einbindung von Bildern auf einer
Webseite.
LastLoginTag Erzeugt die Ausgabe für die Ausgabe, wann ein Benutzer das
letzte Mal im System “Dione“ angemeldet war
MyexperimentsTag Zur Anzeige einer Liste von eigenen Experimente
NavigationTag Zusammen mit den Tags-Klassen “NavigationTabsTag“ und
“NavigationTabTags“ wird hier die Ausgabe des Registerbereiches erzeugt. Sie befindet sich zwischen dem Kopfbereich und dem Arbeitsbereich. Die einzelnen Register werden je nach Status eines Experimentes Aktiv oder Passiv angezeigt. Hat ein Benutzer für ein Experiment
noch keine Data-Mining-Methode ausgewählt, so kann sind die Register “Konfiguration“, “Ergebnis“ usw. passive Register. Desweiteren
beinhaltet das Tag eine Schaltfläche zum Abmelden des Benutzers.
NewsTag Tag zur Ausgabe von Nachrichten für den Benutzer. Diese werden
nach dem Login-Vorgang angezeigt und informieren beispielsweise den
Benutzer über kürzlich abgeschlossene Jobs.
NodeContentTag In einem Entscheidungsbaum kann der Benutzer einzelne
Knoten selektieren und bekommt mit Hilfe dieses Tags eine genaüre
Beschreibung des Knoteninhaltes. Diese werden dann tabellarisch unter
dem Entscheidungsbaum ausgegben.
NoExperimentsTag Für die Anzeige im Falle nicht vorhandener Experimente
PopupFrameTag Anzeigeformatierung eines Popupframes
SmallTabsTag Darstellung eines zweiten schmalen Registerbereiches
SubtreeTag Anzeigeformatierung für das Subtree-Fenster
5.5.6 Paket wui.util
Dieses Paket enthält Beans, Servlets und andere Hilfsklassen.
ChooseMethodBean Diese Klasse wird für die Auswahl der Methode (Algorithmus) benötigt
199
Kapitel 5 Feinentwurf
CSVServlet Servlet zum Hochladen einer CSV-Datei
DioneWuiConvertationException Über diese Klasse erhält man Fehlermeldungen
ExperimentOverviewEditing Hilfsklasse für die Experimentenübersicht
LoginUser Diese Klasse wird für den Login-Vorgang benötigt
MatrixComparator Hilfsklasse zum Vergleichen zweier Matrixobjekte
NewExperimentBean JavaBean, das zur Erzeugung eines neuen Experimentes benötigt wird
News Klasse zum Auslesen und zur Erzeugung von Benutzernachrichten
NewsQueue Realisierung einer Warteschlange für Benutzernachrichten
PNGServlet Servlet zur Erzeugung eines PNG-Bildes für die visülle Ausgabe des Entscheidungsbaumes
SessionListener Klasse für die Erzeugung und Zerstörung von Web-Sessions
StringBean Bean zur Weitergabe von Strings
StringFormatUtils Löscht diverse Zeichen aus einem String zur Vermeidung
von ungewollten Eingaben des Benutzers
SVGServlet Servlet zur Erzeugung eines SVG-Bildes für die visülle Ausgabe
des Entscheidungsbaumes
UploadCSVBean Bean für das Hochladen einer CSV-Datei
200
5.6 Klassen des Moduls Steuerung
5.6 Klassen des Moduls Steuerung
Das Modul Steuerung befindet sich in dem Paket de.unioldenburg.dione.control.
Es ist Teil der Steuerungsschicht und beinhaltet alle Elemente, die für das
Jobmanagement notwendig sind. Außerdem wird hier die allgemeine DioneException
definiert. Alle innerhalb von Dione entworfenen Ausnahmenklassen sind von
dieser Klasse abgeleitet. Eine Übersicht über das Paket bietet Abbildung
5.13.
control
<<Singleton>>
MiningJob
MiningJobManager
- user : User
- jobManagerInstance : MiningJobManager
- experiment : Experiment
- jobList : List
- status : int
+ addJob(miningJob: MiningJob) : void
- startDate : Date
+ removeJob(miningJob: MiningJob) : void
+ MININGJOB_RUNNING : int = 1
+ MININGJOB_NOTRUNNING : int = 2
+ MININGJOB_FINISHED : int = 3
+ getJoblist() : List
+ getuserJobList(user: User) : List
+ getInstance() : MiningJobManager
+ MININGJOB_PAUSED : int = 4
<<create>> - MiningJobManager()
+ MININGJOB_ERROR : int = 5
+ run() : void
- endDate : Date
<<create>> + MiningJob(experiment: Experiment,user: User) :
+ getUser() : User
+ startJob() : int
SimpleJobManager
+ setStatus(status: int) : void
- jobList : Vector
+ setStartDate(start: Date) : void
+ stopJob() : void
+ pauseJob() : void
+ continueJob() : void
+ run() : void
+ setEndDate(end: Date) : void
+ getEndDate() : Date
DioneException
# messageLogged : boolean = false
<<create>> + DioneException(message: String,log: boolean)
<<create>> + DioneException(message: String,cause: Throwable,log: boolean)
<<create>> + DioneException(cause: Throwable,log: boolean)
Abbildung 5.13: Klassendiagramm zum Modul Steuerung
5.6.1 MiningJob
Diese Klasse wird vom Jobmanager genutzt, um einen Job anzusprechen und
zu bearbeiten. Nur Instanzen dieser Klasse können an den JobManager übergeben werden. Zusätzlich wird das Interface Runable implementiert, damit
ggf. jeder einzelne Job als eigener Thread innerhalb der JVM laufen kann.
201
Kapitel 5 Feinentwurf
Paketzugehörigkeit: de.unioldenburg.dione.control
Oberklasse: Interfaces: Runable
Attribute: private Experiment experiment, private DioneUser user, private
int status, private Calendar startDate, private Calendar endDate
Methoden:
• MiningJob(Experiment,User):MiningJob Dieser Konstruktor initialisiert eine neue Instanz der Klasse mit einem Experiment, dessen Algorithmus ausgeführt werden soll und dem dazugehörigen Benutzer.
• getUser(): DioneUser: gibt den Benutzer zurück, dem der Job
zugeordnet ist.
• getStatus(): int gibt den aktuellen Status der Ausführung in
Form einer der vorher beschriebenen Konstanten zurück.
• setStatus(int) Setzt den aktuellen Status in Form einer Statuskonstante. Diese Methode sollte nur von einem JobManager
benutzt werden.
• getStartDate():Calendar Gibt den Zeitpunkt zurück, an dem
die Ausführung gestartet wurde. Wurde die Ausführung noch nicht
gestartet, dann wird null zurück gegeben.
• setStartDate(Calendar) Setzt den Zeitpunkt des Beginns der
Ausführung. Diese Methode sollte nur von einem JobManager benutzt werden.
• getEndDate():Calendar Gibt den Zeitpunkt zurück, an dem
die Ausführung beendet wurde. Wurde die Ausführung noch nicht
beendet oder nur pausiert, dann wird null zurück gegeben.
• setEndDate(Calendar): Setzt den Zeitpunkt des Endes der Ausführung.
Diese Methode sollte nur von einem JobManager benutzt werden.
• startJob(): startet die Ausführung des Jobs.
• run(): Diese Methode wird von Runable vererbt und ermöglicht
das ein MiningJob als neuer Thread gestartet werden kann.
Verhalten im Fehlerfall: Status des Experimentes wird auf Error gesetzt.
202
5.6 Klassen des Moduls Steuerung
5.6.2 MiningJobManager
Mit dieser Klasse wird die Struktur beschrieben, die jeder Jobmanager implementieren muss. Damit nur genau ein Jobmanager in der JVM aktiv ist,
wird die Struktur eines Singleton implementiert. Es wird das Interface Runable mit einbezogen, damit die Implementation als eigener Thread innerhalb
der JVM agieren kann.
Paketzugehörigkeit: de.unioldenburg.dione.control
Oberklasse: Object
Interfaces: Runable
Attribute: Methoden:
• addJob (MiningJob miningJob) Übergabe: miningJob, Rückgabe: -, Funktion: Mit dieser Methode wird ein Job zur Bearbeitung an den Jobmanager übergeben.
• removeJob(MiningJob miningJob) Übergabe: miningJob, Rückgabe: -, Funktion: Diese Methode entfernt, sofern vorhanden, den
übergebenen MiningJob aus der Liste der zu bearbeitenden MiningJobs.
• getJobList() Übergabe: -, Rückgabe: jobList, Funktion: Es wird
eine Liste mit allen Jobs, die sich zu dem Zeitpunkt des Aufrufs
im Jobmanager befinden zurückgegeben.
• getUserJobList(DioneUser user) Übergabe: user, Rückgabe:
userJobList, Funktion: Es wird eine Liste mit allen Jobs, die dem
übergebenen Benutzer zugeordnet sind, zurückgegeben.
• getJob(int experimentID) Übergabe: experimentID, Rückgabe: job, Funktion: Gibt den Job zurück, der zu der übergebenen
Experiment-ID gehört.
• removeJob(int experimentID) Übergabe: experimentID, Rückgabe: -, Funktion: Liefert true und löscht den Job, wenn übergebenes Experiment sich im Jobmanager befindet.
• isExperimentInJobManager(int experimentID) Übergabe:
experimentID, Rückgabe: -, Funktion: Liefert true, wenn übergebenes Experiment sich im Jobmanager befindet, sonst false
203
Kapitel 5 Feinentwurf
• run() Übergabe: -, Rückgabe: -, Funktion: Diese Methode wird
von Runable vererbt und ermöglicht das ein Jobmanager als neuer
Thread gestartet werden kann. Diese Methode ist abstrakt definiert und muss von der Unterklasse implementiert werden.
• MiningJobManager() Übergabe: -, Rückgabe: -, Funktion: Der
Konstruktur wird nur intern von getInstance() verwendet und
ist deshalb als privat markiert. Diese Maßnahme ist Teil des SingletonKonzepts.
• MiningJobManager getInstance() Übergabe: -, Rückgabe: -,
Funktion: Diese Methode wird an Stelle eines Konstruktors aufgerufen und ist Teil des Singleton-Konzepts. Die Rückgabe ist die
Referenz auf die aktuelle Jobmanagerinstanz, die in instance gespeichert ist. Sollte das Klassenattribut instance leer sein, wird
eine neue Instanz eines MiningJobManager erzeugt.
5.6.3 SimpleJobManager
Eine einfache Implementation der abstrakten Klasse MiningJobManager. Der
SimpleJobManager verarbeitet immer nur ein Experiment zur Zeit, andere
Experimente die übergeben werden, werden in eine Warteliste geschickt.
Paketzugehörigkeit: de.unioldenburg.dione.control
Oberklasse: MiningJobManager
Interfaces: Attribute: Methoden:
• run() Übergabe: -, Rückgabe: -, Funktion: Mit dieser Methode
werden die Experiment aus der Joblist nacheinander gestartet.
Wenn die Jobliste leer ist, wird der SimpleJobManager solange in
den wait-zustand geschickt, bis ein neuer Job hinzugefügt wird.
Sobald ein Job vorhanden ist und noch kein anderer Job läuft,
wird ein Thread der Klasse MiningJob ausgeführt und das entsprechende Experiment wird gestartet. Der SimpleJobManager
wartet nun so lange bis das Experiment fertig ist und gibt eine entsprechende Erfolgs- oder Fehlermeldung aus. Der Job wird
aus der Jobliste entfernt und der nächste Job wird bearbeitet.
204
5.6 Klassen des Moduls Steuerung
Verhalten im Fehlerfall: Bei einem Fehler wird der User über eine ErrorNachricht in den News benachrichtigt.
5.6.4 DioneException
Diese Klasse ist die Oberklasse für alle innerhalb von Dione entworfenen
Ausnahmeklassen. Sie bietet die Möglichkeit alle eigenen Ausnahmeklassen
zentral um neue Funktionalität zu erweitern. Es werden drei zusätzliche Konstruktoren implementiert, die die Möglichkeit bieten zu entscheiden, ob die
Ausnahme / der Fehler in der Log-Datei vermerkt werden soll.
Paketzugehörigkeit: de.unioldenburg.dione.control
Oberklasse: Exception
Interfaces: Attribute: Methoden:
• DioneException(message, log): Es wird eine neue Instanz mit
der übergebenen Fehlermeldung zurück gegeben. Außerdem wird
die Fehlermeldung geloggt, wenn log wahr ist.
• DioneException(message, cause, log): Bei diesem Konstruktor kann zusätzlich als Auslöser für das Erzeugen der Instanz ein
Throwable-Objekt übergeben werden.
• DioneException(cause, log): Dieser Konstruktor setzt als Fehlermeldung der Instanz die Fehlermeldung des Auslösers. Es wird
zusätzlich geprüft, ob der Auslöser auch eine Instanz von DioneException
ist. Ist dies der Fall, dann wird die Fehlermeldung nur geloggt,
wenn log wahr ist und die Fehlermeldung des Auslösers nicht geloggt wurde.
205
Kapitel 5 Feinentwurf
5.7 Klassen des Moduls Algorithmen
5.7.1 Paket algorithm
Das Paket algorithm enthält die Dataminingstrukturen als den berechnenden Bestandteil der Dione Workbench. Diese sind in weiteren Unterpaketen
nach Modellierung, Visualisierung sowie allgemeine Hilfsklassen zusammengefaßt. Das Paket model beinhaltet die abstrakten Beschreibungen zu den
Resultaten und Parametern, in seinen Unterpaketen xelopes die implementierten Verfahrensklassen für den Clustering, Entscheidungsbaum und Assoziationsregeln von Xelopes/Weka und in dione den interaktiven Entscheidungsbaumalgorithmus.
algorithm
model
transform
util
<<Singleton>>
AlgorithmFactory
- AlgorithmFactoryInstance : AlgorithmFactory
+ getMiningAlgorithmList() : List
+ getMiningParameterList(algorithmName: String) : List
+ getTransformationMethodList() : List
+ getTransformationParamterList(methodName: String) : List
+ getMiningAlgorithmInstance(algorithmName: String) : MiningAlgorithm
+ getTransformationMethodInstance(methodName: String) : TransformationMethod
+ getInstance() : AlgorithmFactory
- AlgorithmFactory()
# getAlgorithmSpec(algorithmId: int) : AlgorithmSpec
# getTransformationSpec(transformationId: int) : TransformationSpec
# getAlgorithmSpecList() : List
# getTransformationSpecList() : List
DbBasedAlgorithmFactory
Abbildung 5.14: Struktur des Paketes algorithm
AlgorithmFactory
Eine abstrakte Klasse, die als Hauptanlaufstelle des WUI Moduls zum Algorithmen Modul. Sie ist als Singleton entworfen und dient als Schnittstelle
zu den Algoritmusspezifikationen. Der Zugriff auf die Spezifikationen wird
durch die abstrakten Methoden realisiert. Damit ist es möglich verschiedene
Speicherarten wie Tabellen in eine Datenbank oder XML-Dateien zu realisieren ohne den restlichen Quellcode zu ändern. Alle anderen Methoden.
206
5.7 Klassen des Moduls Algorithmen
sind implementiert und greifen auf die Spezifikationen durch die abstrakten
Methoden zu.
Paketzugehörigkeit de.unioldenburg.dione.algorithm
Oberklasse Object
Interfaces keine
Attribute AlgorithmFactory (private static, algorithmFactoryInstance, Referenz zur Instanz der Klasse)
Methoden
• getMiningAlgorithmList() Rückgabe; List, Funktion: Gibt eine Liste mit Namen aller implementierten Datamining Algorithmen zurück.
• getMiningParameterList(algorithmName) Übergabe: String,
Rückgabe: List, Funktion: gibt eine Liste mit den Namen aller Parameter des übergebenen Algorithmus zurück.
• getTransformationMethodList() Rückgabe: List, Funktion: Gibt
eine Liste mit den Namen aller implementierten Attributetransformationsverfahren zurück.
• getTransformationParamterList(methodName) Übergabe:
String, Rückgabe: List, Funktion: Gibt eine Liste mit den Namen
aller Parameter des übergebenen Verfahrens zurück.
• getMiningAlgorithmInstance(algorithmName) Übergabe: String,
Rückgabe: MiningAlgorithm, Funktion: Gibt ein instanziertes( die
Parameter sind mit dem Standardwert initialisiert) MiningAlgorithmObjekt zurück.
• getTransformationMethodInstance(methodName) Übergabe: String, Rückgabe: TransformationMethod, Funktion: Gibt ein
instanziertes( die Parameter sind mit dem Standardwert initialisiert) TransformationMethod-Objekt zurück.
• getInstance() Rückgabe: AlgorithmFactory, Funktion: Die aktuelle Instanz der AlgorithmFactory wird zurück gegeben. Wenn
es noch keine gibt, dann wird diese erzeugt. Es wird immer eine
Implementation dieser Klasse zurückgegeben.
• AlgorithmFactory() Funktion: Dieser Konstruktor wurde als
private markiert, da von außerhalb der Klasse nur über die Methode getInstance() eine Instanz erzeugt werden soll.
207
Kapitel 5 Feinentwurf
• getAlgorithmSpec(algorithmId) Übergabe: Integer, Rückgabe: AlgorithmSpec, Funktion: Gibt ein zu der übergebenen ID
passendes AlgorithmSpec-Objekt zurück.
• getTransformationSpec(transformationId) Übergabe: Integer, Rückgabe: TransformationSpec, Funktion: Gibt ein zu der
übergebenen ID passendes TransformationSpec-Objekt zurück.
• getAlgorithmSpecList() Rückgabe: List, Funktion: Gibt eine
Liste mit allen verfügbaren AlgorithmSpec-Objekten zurück.
• getTransformationSpecList() Rückgabe: List, Funktion: Gibt
eine Liste mit allen verfügbaren TransformationSpec-Objekten
zurück
Verhalten im Fehlerfall Die von den abstrakten Methoden geworfenen
SpecificationRetrievalFailedException-Objekte werden an die aufrufende Klasse weitergereicht.
5.7.2 Paket algorithm.model
Grundlegende Schnittstellen- und Abstraktionsbeschreibungen über die Algorithmen, Resultate und Parameter von Dione bestimmen den Inhalt von
model. Diesem Paket zugeordnet sind ebenso die konkreten Parameterimplementationen für die Typen Boolean, Double, Float, Integer und String,
sowie die Spezialisierungen für Konstanten und das Zeitattribut.
model
dione
xelopes
<<Interface>>
MiningModelBuildResult
<<Interface>>
MiningPredictionResult
<<Interface>>
MiningInteractiveAlgorithm
<<Interface>>
MiningAlgorithm
+ getName() : String
<<Interface>>
MiningInteractiveNextStep
+ getDescription() : String
+ getParameterList() : List
+ setNextStep(nextStep: int) : void
+ getNextStep() : int
<<Interface>>
<<Interface>>
MiningInteractiveStepResult
MiningParameter
+ getName() : String
<<Interface>>
+ getDescription() : String
MiningResult
+ getParameterType() : String
+ getGraphics() : void
+ getValue() : Object
+ setValue(value: Object) : void
+ getDefaultValue() : Object
+ reset() : void
<<Interface>>
MiningVerificationResult
Abbildung 5.15: Struktur des Paketes algorithm.model
208
5.7 Klassen des Moduls Algorithmen
MiningAlgorithm
Implementierungen von MiningAlgorithm kapseln verschiedene DataMiningAlgorithmen. Das MiningAlgorithm-Objekt repräsentiert den zum Experiment gehörenden Algorithmus und bietet Referenzen auf die dazugehörenden
Parameter-Objekte, welche eine Parametrisierung des Algorithmus zulassen.
Paketzugehörigkeit algorithm.model
Oberklasse
Interfaces
Attribute
Methoden
• getName(): Rückgabe: String, Funktion: Gibt den Namen des
Algorithmus zurück.
• getDescription(): Rückgabe: String, Funktion: Gibt eine Beschreibung des Algorithmus zurück.
• getParameters(): Rückgabe: List, Funktion: Gibt eine Liste der
zum Algorithmus gehörenden Parameter (jeweils Objekte vom
Typ Parameter) zurück.
Verhalten im Fehlerfall
Parameter
In den Instanzen des Interfaces MiningParameter werden die einzelnen konfigurierbaren Einstellungen eines Algorithmus festgelegt.
Paketzugehörigkeit algorithm.model
Oberklasse
Interfaces
Attribute
Methoden
209
Kapitel 5 Feinentwurf
• getType(): int: Gibt je nach Typ des Parameters einen Integerwert zurück, welcher einer typspezifischen Konstanten entspricht
(z.B. 1“ für Double), die innerhalb des Interfaces festgelegt ist.
”
Der Typ kann ein einfaches Objekt wie Float und Integer aber
z.B. auch ein MiningResult-Objekt zur Verifikation eines Modells
(siehe UseCases) sein.
• getName(): String: Gibt den Namen des Parameters zurück.
• getDescription(): String: Liefert eine Beschreibung des Parameters.
• getValue(): Object: Liefert den aktuellen Wert des Parameters
in Abhängigkeit des Typs. Der Default-Wert wird beim Instaziieren gesetzt.
• setValue(Object): Setzt den aktuellen Wert des Parameters. Es
ist dabei auf den richtigen Typ zu achten, welcher ein einfaches
Objekt wie Float und Integer aber z.B. auch ein MiningResultObjekt zur Verifikation eines Modells (siehe UseCases) sein kann.
Verhalten im Fehlerfall
MiningResult
Implementierungen von MiningResult kapseln Ergebnisse verschiedener DataMiningAlgorithmen. Dies schließt auch Zwischenergebnisse bei interaktiven Algorithmen mit ein.
Paketzugehörigkeit algorithm.model
Oberklasse
Interfaces
Attribute privat int ResultId
Methoden
• isExperimentCompleted(): boolean: Liefert true, falls tatsächlich
ein Endergebnis festliegt, sonst false (z.B. bei noch zu tätigenden
interaktiven Schritten).
• getComponent(): java.awt.Component: Liefert eine visuelle Darstellung des Ergebnis, welche mit der paint()-Methode des
Component-Objekts erzeugt werden kann.
210
5.7 Klassen des Moduls Algorithmen
• getExportFormats(): List: Gibt eine Liste für das MiningResult verfügbarer Exportformate zurück.
Verhalten im Fehlerfall
MiningModelBuildResult
Als Grundlage aller modellerzeugenden Verfahren deklariert diese abstrakte
Klasse die Ergebnisbereitstellung in PMML-Form. Sie implementiert desweiteren MininResult und ist klonierbar.
Paketzugehörigkeit algorithm.model
Oberklasse
Interfaces MiningResult
Attribute
Methoden
• getPMMLString(): Übergabe: -, Rückgabe: String, Funktion:
Liefert einen String mit dem PMML-codierten Modell zurück.
• clone(): Übergabe: -, Rückgabe: List, Funktion:Gibt eine Liste
für das MiningResult verfügbarer Exportformate zurück.
Verhalten im Fehlerfall Die abstrakte Methode clone() wirft im Fehlerfall
eine CloneNotSuportedException, getPMMLString() eine DioneMiningException.
5.7.3 Paket algorithm.model.dione
Das Paket algorithm.model.dione stellt Klassen und Methoden für die von
DIONE implementierten Algorithmen zur verfügung. Dies ist insbesondere
der Interaktive Entscheidungsbaum.
5.7.4 Paket algorithm.model.xelopes
Das Paket algorithm.model.xelopes stellt Klassen und Methoden aus der
Xelopes Libery zur verfügung, die für die einzelnen Algorithmen benötigt
werden.
211
Kapitel 5 Feinentwurf
dione
InteractiveDecisionTreeAlgorithm
+ InteractiveDecisionTreeAlgorithm()
# getClassifier()
# runAlgorithm() : void
InteractiveDecisionTreeMiningModel
- nextStep : int
+ InteractiveDecisionTreeMiningModel()
+ setNextStep(nextStep: int) : void
+ getNextStep() : int
Abbildung 5.16: Struktur des Paketes algorithm.model.dione
5.7.5 Paket algorithm.model.weka
Das Paket algorithm.model.weka stellt Klassen und Methoden aus der WEKA Libery zur verfügung, die für die einzelnen Algorithmen benötigt werden.
5.7.6 Paket algorithm.util
Das Paket algorithm.util stellt nützliche Funktionen zur verfügung, die immer wieder angesprochen werden.
DioneMiningException
Diese Ausnahmeklasse repräsentiert alle Formen von Ausnahmen, die während
der Ausführung eines Datamining-Algorithmus oder eines Transformationsverfahren auftreten können.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.util
Oberklasse: DioneException
Interfaces: keine
Attribute: keine
Methoden:
212
5.7 Klassen des Moduls Algorithmen
util
DioneMiningException
WrongParameterTypeException
SpecificationRetrievalFailedException
<<Interface>>
ExportFormat
+ getMimeType() : String
+ getName() : String
+ getDescription() : String
+ getExport(miningResult: MiningResult) : Object
Abbildung 5.17: Struktur des Paketes algorithm.util
• keine
5.7.7 Paket algorithm.visualization
In diesem Paket befinden sich die grafischen Klassen. Diese stellen die Anzeigestrukturen und -informationen bereit, die sie aus den Objekten der
Xelopes-Bibleothek extrahieren und als grafische Komponenten bereithalten.
Arrow
Die Klasse Arrow beschreibt die grafischen Pfeile, die als Verbindung zwischen den Knoten dargestellt wird.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.viszualization
Oberklasse: Object
Attribute: private GeneralPath shape, private Component start, end, private int type, private double spikeWidth, spikeLength, private boolean
deko
Methoden:
213
Kapitel 5 Feinentwurf
• isVisible() Übergabe: keine, Rückgabe: boolean, Funktion: Wahrheitswert wahr, wenn Anfang und Ende des Pfeils sichtbar sind,
sonst falsch.
• vgl. java.awt.Shape der Java API1
Verhalten im Fehlerfall: DioneVisualDecisionTreeException extends DioneException
DecisionTreeDataNode
Repräsentiert einen einzelnen Knoten in einem Decisiontree-Objekt.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.viszualization
Oberklasse:
Attribute:
Methoden:
• addChild(DecisionTreeDataNode)
• children()
• getChildAt(int)
• getChildCount()
• getComponent()
• getContent()
• getContentRows()
• getDepth()
• getIndex()
• getLeafCount()
• getLevel()
• getName()
• getNodeID()
• getParent()
• getRoot()
1
http://java.sun.com/j2se/1.4.2/docs/api/
214
5.7 Klassen des Moduls Algorithmen
• isLeaf()
• isRoot()
• setComponent(Component)
• setIndex(int)
• setLeaf(boolean)
• setLevel(int)
• setNodeID(int)
• setParent(DecisionTreeDataNode)
• setRoot(boolean)
Verhalten im Fehlerfall: DioneVisualDecisionTreeException extends DioneException
DioneVisualDecisionTreeException
Fehlerklasse für dieses Paket.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.viszualization
Oberklasse: DioneException
Attribute:
Methoden:
• getMessage()
VisualDecisionTree
Repräsentiert einen Baumobjekt. Dieses Objekt wird auch für den interativen
Algorithmus genutzt.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.viszualization
Oberklasse: Container
Attribute:
Relevante Methoden:
215
Kapitel 5 Feinentwurf
• VisualDecisionTree(DecisionTreeDataNode root, boolean
minimized)
• deselectNode(DecisionTreeDataNode node)
• deselectNodeFromID(int id)
• foldBranches()
• getSelectedNodes()
• getSubtree()
• minimizeNodeFromID(int id)
• paint(java.awt.Graphics graphics)
• paintAll(Graphics graphics, double scale)
• paintComponents(Graphics graphics)
• selectNode(DecisionTreeDataNode node)
• selectNodeFromID(int id)
• setMinimized(boolean minimized)
• setPrintview(boolean printview)
• unfoldBranches()
• unfoldLevels()
• unfoldTree()
Verhalten im Fehlerfall: DioneVisualDecisionTreeException extends DioneException
VisualDecisionTreeNode
Repräsentiert einen einzelnen Knoten in einem VisualDecisiontree-Objekt.
Paketzugehörigkeit: de.unioldenburg.dione.algorithm.viszualization
Oberklasse: component
Attribute:
Relevante Methoden:
• calculatePosition()
• getDepth()
216
5.7 Klassen des Moduls Algorithmen
• getPlaceForNode()
• paint(Graphics graphic)
Verhalten im Fehlerfall: DioneVisualDecisionTreeException extends DioneException
217
Kapitel 5 Feinentwurf
5.8 Klassen des Moduls Datenstrukturen
Im folgenden werden die Klassen des Moduls Datenstrukturen beschrieben.
Aufgeteilt wird nach den Bereichen WUI-DS, Algorithmus Konfiguration
und Traitmatrix. Die einzelnen Abschnitte enthalten jeweils die zugehörigen Klassendiagramme, deren Beschreibung, die DAOs sowie die Tabellenrepräsentation in der Dione Datenbank.
5.8.1 WUI-DS
Hier die Klassen die vorrangig für die WUI wichtig sind.
DioneUser und DioneUserDao Die Klasse DioneUser dient als Datenstruktur um die Benutzerdaten zu halten.
DioneUser
Paketzugehörigkeit de.unioldenburg.dione.data.ojects
Oberklasse Object
Interfaces keine
Attribute String username,String forename, String surname, String eMail,
String password, int id
Methoden
• FUNKTION1 Getter und Setter
Verhalten im Fehlerfall ...
Die Klasse DioneUserDao dient als Data Acces Object für die DioneUser
Klassen, um diese laden und speichern zu können. Wir verwenden eine Implementierung als OracleDioneUserDao für eine Oracle Datenbank.
DioneUserDao
de.unioldenburg.dione.data.access
Oberklasse Object
Interfaces keine
Attribute keine
218
5.8 Klassen des Moduls Datenstrukturen
Methoden
• getDioneUser übergabe: int , Rückgabe: DioneUser, Funktion:
gibt das zu der übergebenen ID gehörende DioneUser- Objekt
zurück
• getDioneUser übergabe: String, Rückgabe: DioneUser, Funktion: gibt das zu dem Namen gehörende DioneUser- Objekt zurück
• getDioneUser übergabe: Experiment, Rückgabe: DioneUser, Funktion: gibt das zum Experiment gehörende DioneUser Objekte zurück
• getDioneUsers übergabe: void, Rückgabe: List, Funktion: gibt
eine Liste mit allen verfügbaren DioneUser Objekten zurück
• destroy übergabe: void, Rückgabe: void, Funktion: schliesst evtl
geöffnetet Verbindungen und Prepared Statements
Verhalten im Fehlerfall Wirft DioneException im Fehlerfall
Experiment und ExperimentDao Die Klasse Experiment repräsentiert
ein Experiment.
Experiment
Paketzugehörigkeit de.unioldeburg.dione.data.objects
Oberklasse keine
Interfaces keine
Attribute id:Integer, name:String, description: String, completed: boolean,
publicExperiment: boolean, creationDate: Calendar, changeDate: Calendar, kindofMethod: Integer, config:Configuration, result: MiningResult; writeProtected: Boolean, owner: Integer, Status: Integer; sowie
diverse Konstanten
Methoden
• Getter und Setter Alle Getter und Setter für die Attribute, ausser Set für Datumsangaben (werden von der Datenbank gesetzt)
und WriteProtected (wird nur vom Jobmanager gesetzt)
• createCopyForUser übergabe: DioneUser, Rückgabe: Experiment, Funktion: erzeugt eine Arbeitskopie vom Aktuellen Experiment für den übergebenen User
219
Kapitel 5 Feinentwurf
Verhalten im Fehlerfall Wirft exceptions
ExperimentDao
de.unioldenburg.dione.data.access
Oberklasse kein
Interfaces keine
Attribute keine
Methoden
• getExperiment übergabe: integer, Rückgabe: Experiment, Funktion: Gibt das Experiment mit der übergebenen id zurück
• getAllPublicExperiments übergabe: void, Rückgabe: List, Funktion: gibt alle öffentlichen Experimente in einer Liste zurück
• getExperimentsForUsesr übergabe: DioneUser, Rückgabe: List,
Funktion: gibt eine Liste mit allen zum Benutzer gehörenden Experimenten zurück
• getExperimentCount übergabe: void, Rückgabe: integer, Funktion: gibt die Anzahl aller Experimente zurück
• getPublicExperimentCount übergabe: void, Rı̈ückgabe: integer, Funktion: gibt die Anzahl aller öffentlichen Experimente zurück
• getExperimentCountForUser übergabe: DioneUser, Rückgabe: integer, Funktion: gibt die Anzahl der zum Benutzer vorhandenen Experimente zurück
• storeExperiment übergabe: Experiment, DioneUser, Rückgabe: void, Funktion: speichert das übergebene Experiment für den
übergebenen Benutzer ab
• updateExperiment übergabe: Experiment, Rückgabe: void, Funktion: überschreibt das übergebene Experiment in der Datenbank
• removeExperiment übergabe: Expriment, Rückgabe: void, Funktion: löscht das übergebene Experiment in der Datenquelle
• destroy übergabe: void, Rückgabe: void, Funktion: schliesst evtl
geöffnete Verbindungen und Prepared Statements
Verhalten im Fehlerfall Wirft im Fehlerfall DioneException
220
5.8 Klassen des Moduls Datenstrukturen
5.8.2 Algorithmus Konfiguration
Hier werden die Klassen der Konfigurationsinformationen von Xelopes berschrieben, sowie die dazugehörigen DAOs.
AlgorithmSpec
Diese Klassen repräsentiert eine Spezifikation eines Algorithmus und gibt
den Typ des Algorithmus an.
Oberklasse keine
Interfaces keines
Attribute algorithmSpecId: Integer, algorithmName: String, functionTypeId:
Integer, functionTypeName: String, algorithmTypeId: Integer algorithmTypeName: String, dataMiningLibraryId: Integer, dataMiningLibraryName: String, dataMiningLibraryVersion: String, version: String, Description: String, AlgorithmClassName: String, GraphicsClassName:
String, parameterList: List, librarySpecificSpecification: Objekt
Methoden
• Methoden: Get und Set Mehoden für alle Attribute
AlgorithmSpecParameter
Diese Klassen repräsentiert eine Den Wert und den Typ eines Paramters von
einem Algorithmus an.
Oberklasse keine
Interfaces keines
Attribute algorithmSpecId: Integer, algoritmSpecParameterId: Integer, parameterName: String, parameterTypeId: Integer, parameterTypeName: String, parameterDefaultValue: String, parameterMinValue: String,
parameterMaxValue: String, description: String, constantValueList: ArrayList
Methoden
• Methoden: Get und Set Mehoden für alle Attribute
221
Kapitel 5 Feinentwurf
TransformationSpecParameter
Diese Klassen repräsentiert die Umwandlung von einem AttributTyp zu einem anderen.
Oberklasse keine
Interfaces keines
Attribute transformationSpecId: Integer, transformationName: String, transformationTypeId: Integer, transformationTypeName: String, inputAttributeTypeId: Integer, inputAttributeTypeName: String, outputAttributeTypeId: Integer, outputAttributeTypeName: String, dataMiningLibraryId: Integer, dataMiningLibraryName: String, dataMiningLibraryVersion: String, transformationClassName: String, description: String,
version: String
Methoden
• Methoden: Get und Set Mehoden für alle Attribute
MiningAlgorithm
Diese Klassen repräsentiert das Interface zwischen dem Dataminig Algorithmus und dem User-Interface. Es gibt an, welche Methoden von einen Algorithmus benötigt werden, so daß der User ihn benutzen kann.
Oberklasse keine
Interfaces Interface zwischen MinigAlgorithm und UserInterface
Attribute keine
Methoden
• getAlgorithmSpecId übergabe: - Rückgabe: -
• getName Get und Set Mehoden für alle Attribute
• getDescription Get und Set Mehoden für alle Attribute
• getParameterList Get und Set Mehoden für alle Attribute
• getFunctionType Get und Set Mehoden für alle Attribute
• getResult Get und Set Mehoden für alle Attribute
• startAlgorithm übergabe: Experiment, Rückgabe: -
222
5.8 Klassen des Moduls Datenstrukturen
5.8.3 Traitmatrix
Hier werden die Klassen der Traitmatrix beschrieben.
AttributeDescription
Diese Klasse repräsentiert ein einzelnes Attribut das Webquery aus der LedaTraitbasse bekommen kann.
Variablen traitId: Integer, internalName: String, externalName: String, usedForGrouping: Integer, attributeType: Integer, valueType: Integer, isAggregationResult: Integer, usedForOrdering: Integer, shortTableName: String
Methoden get, set, Konstruktor, clone
Oberklasse keine
Interfaces keines
Beschreibung der wichtigesten Variablen
attributeType Kann die Werte: ORDINAL, NOMINAL, INTEGER, DOUBLE oder String, wie in DBAccesConstants angegeben annehmen.
valueType Entspricht den Konstanten aus java.sql.Types.
Beschreibung der Methoden
Konstruktor Initialisiert die Attributewerte
getset Get-Methoden für alle Werte mit Einschränkungen (WritePtotected,
Zeitangaben)
223
Kapitel 5 Feinentwurf
Abbildung 5.18: Klassendiagramm AttributeDescription
AtributeDescriptionList
Ein Vektor mit Attributbeschreibungen(AttributeDescription)
Paketzugehörigkeit
Oberklasse Vector
Interfaces keines
Attribute
Methoden
• Konstruktor Funktion: ruft Superklassenkonstruktor auf
• getAttributeDescription übergabe: Integer, Rückgabe: AttributeDescription, Funktion: Gibt das indizierte AttributeDescription Objekt zurück.
Verhalten im Fehlerfall
SingleTraitResult
Repräsentiert das Ergebnis eines Traits zu der mit Webquery gestellten Anfrage. Ein SingleTraitResult kann eine oder mehrere Spalten enthalten.
224
5.8 Klassen des Moduls Datenstrukturen
Attribute traitId: Integer, attributeDescriptionList: AttributeDescriptionList, resultSet : Vector
Methoden Konstruktor, getset
Oberklasse keine
Interfaces keines
Beschreibung der Attribute
traitId Funktion : Id des Trait zu dem das Resultat gehört
attributeDescriptionList Funktion : Enthält die Attributbeschreibungen,
der Reihenfolge nach passend wie im ResultSet Vector spaltenweise.
ResultSet Funktion : Enthält die Daten des Query Ergebnisses
QueryResultList
Repräsentiert ein vollständiges WebQuery- Ergebnis, bestehend aus einem
oder mehreren SingleTraitResults.
Attribute traitId: Integer, attributeDescriptionList: AttributeDescriptionList, resultSet : Vector
Methoden Konstruktor, addSingleTraitResult, containsResultForTrait, getSingleTraitResult
Oberklasse Vector
Interfaces keines
Konstruktor Funktion: ruft Superklassenkonstruktor auf
addSingleTraitResult übergabe: SingleTraitResult Rückgabe:nichts, Exception wenn Trait schon vorhanden, Funktion : fügt einen Trait hinzu
containsResultForTrait übergabe: Integer(traitId), Rückgabe: Boolean, Funktion: gibt True zurück wenn die übergebene TraitId bereits vorhanden
ist.
getSingleTraitResult übergabe: Integer(traitId), Rückgabe: SingleTraitResult, Exception wenn traitId nicht enthalten, Funktion: Gibt SingleTraitResult passend zur übergebenen TraitId zurück.
225
Kapitel 5 Feinentwurf
TraitMatrix
Die Klasse Traitmatrix repräsentiert die ’Traitmatrix’ an sich. Die Traitmatrix setzt sich aus Spalten (Coloumn) zusammen.
de.unioldenburg.dione.data.objects
TraitMatrix
AttributeDescriptionList
+ UNUSED_ROW
:int = 0
+ MODEL_CREATION_ROW
:int = 1
+ PREDICTION_ROW
:int = 2
+ VERIFICATION_ROW:int = 4
~rowsIntendedPurpose :ArrayList
~getAttributeDescription
*
+ findColumn (anAttributeDescription :AttributeDescription ):int
+ removeColumn (aColumn :int ):void
+ removeColumn (anAttributeDescription :AttributeDescription ):void
+ removeRow (aRow:int ):void
~checkRowsIntendedPurpose ():void
+ addColumn (aColumn :Column ):void
+ insertColumn (aColumn :Column ,aCol:int ):void
+ getColumns ():List
+ setColumns (columns :List ):void
+ getDescription ():String
+ setDescription (description :String ):void
+ getTraitMatrixId ():int
+ setTraitMatrixId (traitMatrixId :int ):void
+ getRow (row :int ):List
+ getRowCount ():int
+ clone ():Object
+ getUserId ():int
+ setUserId (userId :int ):void
+ getRowsIntendedPurpose ():ArrayList
+ setRowsIntendedPurpose (rowsIntendedPurpose :ArrayList ):void
+ getAttributeDescriptionList ():AttributeDescriptionList
AttributeDescription
+ getTraitId ():int
+ setTraitId (aTraitId :int ):void
+ getInternalName ():String
+ setInternalName (aName :String ):void
+ getExternalName ():String
+ setExternalName (aName :String ):void
+ getUsedForGrouping ():int
+ setUsedForGrouping (aTruthValue :int ):void
+ getIsAggregationResult ():int
+ setIsAggregationResult (aTruthValue :int ):void
+ getUsedForOrdering ():int
+ setUsedForOrdering (aTruthValue :int ):void
+ getValueType ():int
+ setValueType (aValueType :int ):void
+ getAttributeType ():int
+ setAttributeType (anAttributeType :int ):void
+ getShortTableName ():String
+ setShortTableName (aName :String ):void
+ toString ():String
+ getStringVal (indent :String ,topLevel :AttributeDescription
+ equals (obj :Object ):boolean
+ clone ():Object
*
Column
+ getAttributeDescription ():AttributeDescription
+ setAttributeDescription (attributeDescription :AttributeDescription
+ getData ():List
+ setData (data :List ):void
+ toArray ():Object[]
+ clone ():Object
(anIndex :int ):AttributeDescription
):void
):String
WebQueryConstants
(from leda_traitbase_webquery )
+ NOMINAL:int = 1
+ ORDINAL:int = 2
+ NUMERIC:int = 3
+ DESCRIPTIVE
:int = 4
Abbildung 5.19: Klassendiagramm Traitmatrix
Column
Die Klasse Coulumn repäsentiert eine Spalte in der Traitmatrix (eine Spalte
kann wiederum meherer Spalten enthalten). Es wird jeweils eine AttributeDescription mit den Informationen gespeichert sowie eine ArrayList die die
tatsächlichen Daten enthält.
DataImport
DataImport ist ein Interface,das die verschiedenen Import- und Reimportmöglichkeiten der Traitmatrix definiert. Implementiert werden zunächst der CSVImport, der eine vom Benutzer hochgeladenes CSV- Datei in eine Traitmatrix importieren kann, sowie der WebqueryImport, der die von WebQuery
226
5.8 Klassen des Moduls Datenstrukturen
übergebenen Datenstrukturen einlesen kann. Die ReImport- Methoden dienen jeweils dazu zu einer bestehenden Matrix weitere Daten hinzuzufügen.
Abbildung 5.20: Klassendiagramm DataImport
DataExport
DateExport ist ein Interface, dass die verschiedenen Exportmethoden der
Traitmatrix darstellt. Zunächst soll ein einen XelopesExport geben, der eine
Traitmatrix in einen MinigInputStream transformiert wie Xelopes in verwenden kann, sowie ein CSV- Skeleton Export, der als Headervorlage einer CSV
Datei dienen kann, die dann vom Benutzer offline verändert werden kann.
Abbildung 5.21: Klassendiagramm DataExport
WebQueryImport
Importiert eine von WebQuery erzeugte TraitMatirx
de.unioldenburg.dione.data.objects
227
Kapitel 5 Feinentwurf
Oberklasse Object
Interfaces DataImport
Attribute keine
Methoden
• matrixImport übergabe: Object Data (Eine Liste mit 2 Einträgen(Benutzername und Queryname)), Rückgabe :TraitMatrix,
Funktion: Ruft den WebQueryCLient auf, dieser setzt dann die
von WebQuery in der Datenbank gespeicherte Query auf. Die
daraus erzeugte TraitMatrix wird dann in das Dione TraitMatrixformat konvertiert.
Verhalten im Fehlerfall Fehlermeldung bei unbekanntem Datentyp
WebqueryConstants
Definiert die Zugriffskonsten für das Webquery, die in einigen anderen Klassen verwendet werden. Es werden Zwei Arten von Konstanten unterschieden:
Wahrheitswerte und Wertetypen. Typ ist Integer.
Attributtypen:
NOMINAL = 1 Funktion : Nominalwert
ORDINDAL = 2 Funktion : Ordinalwert
NUMERIC = 3 Funktion : Zahlenwert
DESCRIPTIVE = 4 Funktion : Text
228
5.8 Klassen des Moduls Datenstrukturen
Abbildung 5.22: Klassendiagramm WebQueryConstants
TraitMatrixExportStream Der TraitMatrixExportStream implementiert
einen MiningInputStream von Xelopes.
TraitMatrixExportStream
Paketzugehörigkeit de.unioldenburg.dione.data.objects
Oberklasse MiningInputStream
Interfaces keine
Attribute TraitMatrix traitMatrix, integer methodkind, integer usedRowCount
Methoden
• Konstruktor übergabe: TraitMatrix aTraitMatrix, integer kindOfMethod
229
Kapitel 5 Feinentwurf
• recognize übergabe: void, Rückgabe: MiningDataSpecification,
Funktion: erzeugt die MetaDaten und gibt sie zurück
• reset übergabe: void, Rückgabe: void, Funktion: setzt den CursorVector zurück
• next übergabe: void, Rückgabe: void, Funktion: wählt die nächste
zu benutzenden Zeile an
• move übergabe: integer position, Rückgabe: Boolean, Funktion:
Setzt den Cursor auf die übergebene Position, liefert false wenn
ungültige Position
• read übergabe: void, Rückgabe: MiningVector, Funktion: Liefert
einen MiningVector zurück
5.9 Datenbank
In diesem Abschnit wird die DIONE Datenbank beschrieben, die eine essentielle Datenstruktur für die Workbanch darstellt. Denn in dieser Datenbank
werden die Konfigurationen von Experimenten, die Experimente selbst sowie die dazugehörigen Traitmarizen und die Ergebnisse gespeichert, also alle
Daten die für den Datamining Vorgang wichtig sind. Ferner wird auch die Algorithmusspezifikation in dieser Datenbank vorgehalten, welches im zweiten
Abschnitt dieses Kapitel zufinden ist.
Die Benutzerverwaltung ist von der LEDA Datenbank (Siehe: www.ledatraitbase.org) übernommen, da diese bereits mit vorhandenen Usern existierte. Pflanzen Merkmale und reine Daten die erst noch für das Datamining
aufgearbeitet werden müssen finden sich nicht in der DIONE Datenbank,
können aber in Form von Experimenten und Traitmatrizen importiert werden.
Es werden folgende SQL-Skripte benötigt um die DIONE Datenbank anzulegen:
1. createDIONE.sql Dieses Skript erzeugt die benötigte Tabellenstruktur
für die DIONE Datenbank, samt Triggern und Sequences.
2. insertIntoDIONE.sql Die Tabellen werden mit diesem Skript mit einem
initialen Katalog der in DIONE verwendeten Algorithmen gefüllt.
230
5.9 Datenbank
5.9.1 Tabellenstruktur Experiment
Dieser Abschnit widment sich den Tabellen und Datenstrukturen die notwendig sind, um Experimente in ihrem vollem Umfang, also samt Traitmatrix,
Konfiguration und Ergbnis abzuspeichern und zubenutzen.
Traitmatrix
Schema: DIONE
Typ: Tabelle
Beschreibung: In dieser Tabelle werden die Traitmatrixen samt all ihrer
Daten gespeichert.
Attribute:
Name
TraitmatrixID
UserID
Typ
NUMBER
NULL
NUMBER
NULL
NOT
NOT
Description
VARCHAR2(4000)
Traitmartix
BLOB
MatrixVersion
NUMBER(3)
Key
PK
Beschreibung
Primärschlüsselfeld
Id
des
Benutzers
der die Traitmatrix
erzeugte
Beschreibung
der
Traitmatrix
Die komplette Traitmatrix
gibt die Version der
Traitmatrix an
Configuration
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Configuration von DataminingAlgorithmen. Also alle Einstellungen die für ein ausführen des Experimentes
notwendig sind.
Attribute:
231
Kapitel 5 Feinentwurf
Name
ConfigID
Typ
NUMBER
NULL
NOT
Key
PK
Beschreibung
Primärschlüsselfeld
wird fortgesetzt auf nächster Seite
232
5.9 Datenbank
fortgesetzt von vorheriger Seite
Name
UserID
Typ
NUMBER
NULL
Key
ResultID
Name
NUMBER NOT
NULL
VARCHAR2(500)
isPublic
NUMBER(3)
AlgorithmSpecID
NUMBER(8)
NOT
Beschreibung
Id des Benutzers der
die Konfiguration erzeugte
Id des Ergebnisses von
der Konfiguration
Name der Konfiguration bzw. des Experimentes
gibt an ob ein Experiment öffentlich ist
gibt die zum Experiment dazugehörige Algorithmus Spezifikation
AlgorithmSpecParameterValue
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Werte für die Parameter der
Algorithmus Spezifikation
Attribute:
Name
Typ
Key
AlgorithmSpecParameterID
NUMBER NOT PK
NULL
ConfigID
NUMBER NOT PK
NULL
Value
VARCHAR2(4000)
Beschreibung
Primärschlüsselfeld
Primärschlüsselfeld
enthält die Werte der
Parameter
Experiment
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet alle Informationen die zu einem
Experiment gehören. So zum Beispiel auch die ConfigID
Attribute:
233
Kapitel 5 Feinentwurf
234
5.9 Datenbank
Name
ExperimentID
ConfigID
UserID
ResultID
Description
TraitmartixID
Typ
NUMBER
NULL
NUMBER
NULL
NUMBER
NULL
NOT
Key
PK
Beschreibung
Primärschlüsselfeld
NOT
PK
Primärschlüsselfeld
NOT
NUMBER NOT
NULL
VARCHAR2(4000)
NUMBER
NULL
NUMBER
NULL
NOT
FlorianState
NUMBER
NULL
NOT
Name
VARCHAR2(500)
isPublic
NUMBER(3)
changeDate
TIMESTAMP
creationDate
TIMESTAMP
kindOfMethod
NOT
Id
des
Benutzers
der das Experiment
erzeugte
Id des Ergebnisses von
dem Experiment
Beschreibung des Experiments
Die ID der zugehörigen
Traitmatrix
gibt die verwendete
Methode bzw. Algorithmus an
gibt den internen Zustand des Experimentes an
Name des Experimentes
gibt an ob ein Experiment öffentlich ist
gibt das Änderungsdatum an
gibt das Enstehungsdatum an
MiningResult
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet das Ergebnisses des Dataminings
Attribute:
235
Kapitel 5 Feinentwurf
Name
ResultID
Typ
NUMBER
NULL
NOT
Key
PK
Beschreibung
Primärschlüsselfeld
wird fortgesetzt auf nächster Seite
236
5.9 Datenbank
fortgesetzt von vorheriger Seite
Name
Result
Typ
BLOB
Key
Beschreibung
enthält das komplette
Ergebniss des Datamining
News
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle speichert die News, News sind zum Beipiel,
dass ein Experiment abgeschlossen ist.
Attribute:
Name
NewsID
News
Typ
Key
NUMBER NOT PK
NULL
NUMBER NOT
NULL
VARCHAR2(4000)
creationDate
TIMESTAMP
UserID
Beschreibung
Primärschlüsselfeld
ID des Benutzers der
die News erzeugte
Enthält die Neuigkeiten als Text
gibt das Enstehungsdatum an
5.9.2 Tabellenstruktur Algorithmusspezifikationen
Die Spezifikationen der Algorithmen, die dem Modul WUI über die AlgorithmFactory zur Verfügung gestellt werden, werden in der Datenbank in
einer Tabellenstruktur unter dem Schema DIONE zur Verfügung gestellt.
Abbildung 5.23 zeigt diese Struktur.
237
Kapitel 5 Feinentwurf
Abbildung 5.23: Tabellenstruktur Algorithmusspezifikationen
238
5.9 Datenbank
Im folgenden werden die einzelnen Tabellen beschrieben.
AlgorithmType
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet den Typ des Datamining-Algorithmus.
Beispiele für den Typ sind decisionTree“ oder centerBasedClustering“
”
”
Attribute:
Name
AlgorithmTypeId
AlgorithmTypeName
Typ
NUMBER NOT
NULL
VARCHAR2(50)
Key
PK
Beschreibung
Primärschlüsselfeld
Name des Algoritmustyps
FunctionType
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Funtktionstypen von DataminingAlgorithmen. Ein Beispiel für die Funktion wäre Classification“.
”
Attribute:
Name
FunctionTypeId
FunctionTypeName
Typ
NUMBER NOT
NULL
VARCHAR2(50)
Key
PK
Beschreibung
Primärschlüsselfeld
Name des Funktionstyps
AttributeType
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die einzelnen Attributtypen, die
als Parameter für die Algorithmen oder Transformationsverfahren genutzt
werden.
Attribute:
239
Kapitel 5 Feinentwurf
240
5.9 Datenbank
Name
AttributeTypeId
AttributeTypeName
Typ
NUMBER NOT
NULL
VARCHAR2(200)
Key
PK
Beschreibung
Primärschlüsselfeld
Name des Attributtyps
TransformationType
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die einzelnen Typen von Attributtransformationsverfahren. Unter anderem gehört die Nullwertersetzung“ da”
zu.
Attribute:
Name
TransformationTypeId
TransformationTypeName
Typ
NUMBER NOT
NULL
VARCHAR2(50)
Key
PK
Beschreibung
Primärschlüsselfeld
Name des Verfahrens
DataMiningLibrary
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Namen der einzelnen DataminingBibliotheken.
Attribute:
Name
DataMiningLibraryId
DataMiningLibrary
Name
Version
Typ
NUMBER NOT
NULL
VARCHAR2(50)
VARCHAR2(10)
Key
PK
Beschreibung
Primärschlüsselfeld
Name der Bibliothek
Versionnummer
Bibliothek
der
241
Kapitel 5 Feinentwurf
AlgorithmSpec
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Spezifikation der Algorithmen.
Die Spezifikation der Parameter zu einem Algorithmus befindet sich in der
Tabelle AlgorithmSpecParameter.
Attribute:
Name
AlgorithmSpecId
AlgorithmName
FunctionTypeId
AlgorithmTypeId
DataMiningLibraryId
Typ
NUMBER NOT
NULL
VARCHAR2(50)
NUMBER NOT
NULL
NUMBER NOT
NULL
NUMBER NOT
NULL
AlgorithmClassName
VARCHAR2(200)
GraphicsClassName
VARCHAR2(200)
Description
VARCHAR2(500)
Version
VARCHAR2(10)
Key
PK
FK
FK
FK
Beschreibung
Primärschlüssel
Name des Algorithmus
Fremdschlüssel zur Tabelle FunctionType
Fremdschlüssel zur Tabelle AlgorithmType
Fremdschlüssel
zur
Tabelle DataMiningLibrary
Name der Javaklasse,
die zum Algorithmus
gehört
Name der JavakLasse,
die Grafik des Modells
erzeugt
Beschreibung des Algorithmus
Version des Algorithmus
AlgorithmSpecParameter
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beschreibt die Parameter zu einem DataminingAlgorithmus. Der Primärschlüssel besteht hier aus zwei Feldern, damit eine
eindeutige Zuordnung mehrerer Parameter zu einem bestimmten Algorithmus gegeben ist.
Attribute:
242
5.9 Datenbank
243
Kapitel 5 Feinentwurf
Name
AlgorithmSpecId
Typ
NUMBER
NOT NULL
Key
PK,
FK
AlgorithmSpecParameterId NUMBER
PK
NOT NULL
ParameterName
VARCHAR2(50)
ParamterTypeId
NUMBER
FK
NOT NULL
ParameterDefaultValue
VARCHAR2(50)
Description
VARCHAR2(500)
Beschreibung
Primär- und Fremdschlüsselfeld zur Tabelle AlgorithmSpec
Primärschlüsselfeld
Name des Parameters
Fremdschlüssel zur Tabelle AttributType
Standardwert des Parameters
Beschreibung
TransformationSpec
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beinhaltet die Spezifikation der Attributtransformationsverfahren. Die Spezifikation der Parameter zu einem Verfahren
befindet sich in der Tabelle TransformationSpecParameter.
Attribute:
Name
TransformationSpecId
TransformationName
TransformationTypeId
Typ
Key
NUMBER
PK
VARCHAR2(50)
NUMBER
FK
NOT NULL
InputAttributeTypeId
NUMBER
NOT NULL
NUMBER
NOT NULL
NUMBER
NOT NULL
OutputAttributeTypeId
DataMiningLibraryId
FK
FK
FK
TransformationClassName
VARCHAR2(200)
Description
VARCHAR2(500)
Beschreibung
Primärschlüssel
Name des Verfahrens
Fremdschlüssel zur Tabelle TransformationType
Fremdschlüssel zur Tabelle AttributType
Fremdschlüssel zur Tabelle AttributType
Fremdschlüssel
zur
Tabelle DataMiningLibrary
Name der Javaklasse
des Verfahrens
Beschreibung des Verfahrens
wird fortgesetzt auf nächster Seite
244
5.9 Datenbank
fortgesetzt von vorheriger Seite
Name
Version
Typ
Key
VARCHAR2(10)
Beschreibung
Version des Verfahrens
TransformationSpecParameter
Schema: DIONE
Typ: Tabelle
Beschreibung: Diese Tabelle beschreibt die Parameter zu einem Attributtransformationsverfahren. Der Primärschlüssel besteht hier aus zwei Feldern,
damit eine eindeutige Zuordnung mehrerer Parameter zu einem bestimmten
Verfahren gegeben ist.
Attribute:
Name
TransformationSpecId
Typ
NUMBER
NULL
NOT
TransformationSpec
ParameterId
ParameterName
ParamterTypeId
NUMBER NOT
NULL
VARCHAR2(50)
NUMBER NOT
NULL
ParameterDefaultValue VARCHAR2(50)
Description
VARCHAR2(500)
Key
PK,
FK
PK
FK
Beschreibung
Primär- und Fremdschlüsselfeld zur Tabelle Transformationspec
Primärschlüsselfeld
Name des Parameters
Fremdschlüssel zur Tabelle Attributtype
Standardwert des Parameters
Beschreibung
245
Kapitel 5 Feinentwurf
5.10 Ausgewählte Abläufe
Für die Beschreibung der einzelnen Module der DIONE-Workbench sollen
im folgenden die grundlegenden Abläufe erläutert werden. Im Vordergrund
steht die modulübergreifende Interaktion der einzelnen Klassen, wodurch sich
die im vorigen beschriebenen Teilfunktionalitäten zu einem Gesamtüberblick
vereinen lassen.
5.10.1 Interaktiver Entscheidungsbaumalgorithmus
Das Diagramm 5.24 stellt den sequenziellen Ablauf der Verfahrensnutzung
dar. Der Benutzer startet ein Experiment, in dem die Konfiguration schon
eingegeben wurde. Damit beginnt die Schleife, die erst beendet wird, wenn
der Baum fertig aufgebaut ist. Der Algorithmus wird initialisiert und fordert
die Eingabedaten aus dem Experimentobjekt an. Diese sind die Traitmatrix
und das Zwischenschrittresultat des Ergebnisbaums, der im ersten Schritt
nur aus einem Wurzelelement besteht. In den folgenden Schritten wird der
Baum durch einen erweiterten ersetzt. Nach Darstellung der Baumstruktur
und des Informationsgewinns für Attributsplitting wählt der Benutzer an
dem aktuellen Knoten die nächste Eingabe aus. Diese kann entweder Pruning oder Splitting nach einem Attribut sein. Diese Eingabe wird in das Experiment eingetragen und der Algorithmus neu gestartet. Im letzten Schritt
steht die Splittingfunktion nicht mehr zur Verfügung, der Baum kann durch
Pruning aber in vorige Teilergebnisse zurückgeführt werden.
246
5.10 Ausgewählte Abläufe
<WUI>
<Steuerung>
<ALG>
Experiment
starte IEBVerfahren
starte IEB-Verfahren
starte IEBA
hole Traitmatrix
liefereTraitmatrix
hole Benutzerschritt
liefere Benutzerschritt
(im 1. Schritt keinen)
loop
erzeuge Baummodell
im x+1.Schritt
Erfolgreicher
Interaktiver Schritt
Erfolgreicher
Interaktiver Schritt
trage
Teilbaummodel ein
fordere Baummodell an
liefere Baummodell
Darstellung des
Zwischenresultats
Nicht fertig?:
Bestimme
nächsten Schritt
frage Status ab
liefere Status (fertig/nicht fertig)
Trage nächsten Benutzerschritt ein
Abbildung 5.24: Sequenzdiagramm zum Aufruf des Interaktiven Entscheidungsbaumalgoritmus (IEBA)
247
Kapitel 5 Feinentwurf
5.10.2 Zusammenspiel von JSP und anderen Elementen
Das folgende Kapitel soll einen Einblick in die Realisierung von den JSP’s mit
den Struts-Elementen (Tags und Actions), den Beans und Servlets geben.
Allgemeines
Um lange Pfade zu vermeiden, werden am Anfang jeder JSP einige Definitionen vorgenommen:
<%@
<%@
<%@
<%@
<%@
<%@
taglib uri="/WEB-INF/DioneTags.tld" prefix=\"dione\" %>
taglib uri="/WEB-INF/DioneTableTags.tld" prefix=\"table" %>
taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
page import="de.unioldenburg.dione.algorithm.model.*" %>
page import="de.unioldenburg.dione.data.objects.*" %>
Datentransfer
Unter Umstaenden mussen Daten von einer Seite zur naechsten uebergeben
werden. Dieser Transfer wird auf unterschiedliche Weise realisiert:
• Ueber einen Request: “request.getAttribute(String)“. Die Daten werden ueber ein an die URL angehaengt und an die naechste Seite weitergereicht.
• Mit session-Variablen: session.getAttribue(String) Verwaltet wird die
Session vom Tomcat-Server.
• Ueber Beans: “<jsp:useBean id=“...“ class=“...“ scope=“...“/ >“
Die Weitergabe von Daten an Actions werden ueber HTML-Formulare realisiert. Mit der Methode “public ActionForward execute(...)“ wird die Action ausgefuehrt. Durch die Parameteruebergabe “ActionMapping mapping“,
“ActionForm form“, “HttpServletRequest request“ und “HttpServletResponse
response“ erhaehlt man die notwendigen Daten. Diese koennen dann mit
“HttpSession session = request.getSession();“ und “request.getParameter(
formularelementname);“ verwendet werden. Alle Uebergaben sind hierbei
vom Typ String.
248
5.10 Ausgewählte Abläufe
Verwendung von Tags
Tags werden im Paket “wui.tags“ implementiert und koennen dann mit dem
jeweiligen Namen eingebunden werden. In diesem Beispiel wird die Beschreibung eines Knoten als Tag mit Namen “nodeContent“ auf einer JSP eingebunden:
<dione:nodeContent ></dione:nodeContent >
Alle Tags mit Ausnahme von Tabellen-Tags werden mit “dione:NAME“ eingebunden. Dies ergibt sich auf den zuvor definierten taglibs. Fuer TabellenTags muss der Bezeichner “table:NAME“ lauten.
Verwendung von Actions
Actions sind ein wesentlicher Bestandteil der Funktionalitaet von Struts.
Der grobe Aufbau wurde bereits erlaeutert. Actions werden normalerweise
über Formulare ausgefuehrt. In dem form-Tag wird dann im Attribut action
der jeweilige Name der Action eingetragen. Dieser lautet wie die Klasse mit
einem angehaengten “.do“.
Beispiel: <form action=“TestAction.do“ method=“post“ >
In der struts-config.xml, die sich im Verzeichnis WEB-INF befindet, muss
nun die Action definiert werden:
<action path="/jsp/BeispielAction"
type="de.unioldenburg.dione.wui.action.BeispielAction"
name="BeispielAction"
scope="request"
input="/jsp/Beispiel.jsp">
</action>
Das Attribut type legt fest, welche Klasse ausgeführt werden soll. Alle Actions befinden sich im Paket “wui.action“. Jede dieser Action-Klassen erbt
von DioneAction.
Ein Sonderfall bildet die Auswahl eines Knotens in einem Ergebnisbaum.
Da die Selektion ueber eine Image-Map erfolgt, konnten Actions nicht über
Formulare realisiert werden. HTML laesst bei Image-Maps lediglich normale
Links (href) zu. In dem Link wird nach der “TreeAction.do“ eine Variable
zur Identifizierung genutzt. Auch diese Action muss in der struts-config.xml
eingetragen werden.
249
Kapitel 5 Feinentwurf
Sprach-Bundles
Die Webseiten von Dione unterstuetzen mehrere Sprachen (englisch und
deutsch). Eine Erweiterung fuer weitere Sprachen ist ohne Aenderung der
JSP’s möglich. Jede textuelle Ausgabe wird wie folgt in einer JSP erzeugt:
“<bean:message key=“...“/>“. Dabei enthält “...“ den Schlüssel. Fuer jede
Sprache gibt es eine Datei im Paket src.de.unioldenburg.dione.wui.lang, die
zu diesem Schlüssel den jeweiligen Text ersetzt. Kann keine Sprache gefunden
werden, wird in der Datei “Dione.properties“ nach dem Schluessel gesucht.
Fuer die Ausgabe der Algorithmentexte sind gesonderte Sprachdateien vorhanden.
250
Kapitel 6
Umsetzung und Implementation
6.1 Unterschiede zum Entwurf
Aufgrund geänderter Rahmenbedingungen gibt es eine Menge Differenzen
zwischen der tatsächlichen Umsetzung und der Lösung, die im Entwurf forgesehen worden ist. Dies betrifft einerseits die Unterschiede die zwischen den
Klassen, die implementiert worden sind, und dem Entwurf der Klassen aber
vor allem geänderte Abläufe.
Hauptgrund hierfür sind geänderte Anforderungen, die sich ergeben haben,
als nach Abschluss der Entwurfsphase nachträglich entschieden worden ist,
die Erstellung von Trait-Matrizen nicht über DIONE selbst forzunehmen,
sondern LEDA WebQuery hierfür zu benutzen. Diese Entscheidung hat sich
in erheblichen Maße auf Datenstrukturen und Abläufe ausgewirkt.
Aus Benutzesicht bedeutet dies insbesondere, dass DIONE auf der Datenauswahlseite ausschließlich den Import von Eingabedaten anbietet. Diese
können entweder über LEDA WebQuery oder per CVS-Upload importiert
werden oder aus bereits erstellten Experimenten kopiert werden. Der genaue
tatsächlich umgesetzte Workflow ist im der Dokumentation von DIONE begelegten Handbuch abgebildet, auf welches an dieser Stelle verwiesen wird.
Weiterhin hat die Entscheidung, WebQuery zu verwenden, Änderungen an
der Datenstruktur und den Schnittstellen in der Form bewirkt, dass die DIONE Datenstruktur, die eine Trait Matrix abbildet, entsprechend an die von
WebQuery angepasst werden musste. Die tatsächliche Umsetzung in Form
der Implementierung kann im Doxygen Onlinedokument nachgelesen werden.
251
Kapitel 6 Umsetzung und Implementation
252
Kapitel 7
Ausblick
Nach einem Jahr Entwicklungsarbeit wurde dem Anwender eine umfangreiche Software zur Verfügung gestellt, die wie jede jedoch keinen Anspruch
auf Vollständigkeit erhebt. Daher sollen an dieser Stelle Anregungen gegeben werden, wie die Webanwendung verbessert und erweitert werden kann.
Auf die einfache Erweiterungsmöglichkeit wurde schon in der frühen Phase
der Entwicklung großen Wert gelegt.
7.1 Vorschläge zur Erweiterung
Auswahl der Daten für die Vorhersage
Zur Zeit können nur Daten eines erstellten Modells zur Vorhersage genutzt
werden. Der Anwender erstellt ein neues Experiment vom Typ MModel Predictionünd selektiert dann Daten eines zuvor erstellten Modells, in der die
Daten zur Vorhersage enthalten sein müssen. Wünschenswert wäre es, dem
Anwender die Möglichkeit zu geben, unabhängig vom Modell Daten zu importieren.
Ergebnisanzeige für Modellvorhersage
Die Ergebnisanzeige für die Modellvorhersage beschränkt sich auf eine Tabelle. Für den Anwender könnten noch weitere Informationen und Darstellungen
nützlich sein.
Baumergebnis als Trait-Matrix
Entscheidungsbäume werden in zwei möglichen Ansichten dargeboten. Unter
Umständen wäre eine Ausgabe als Trait-Matrix hilfreich.
Optimierte Integration von Webquery
Eine Anforderung an das Projekt war die Anbindung an dem bereits existierenden Webquery-Builder. Die Kommunikation zwischen DIONE und Webquery funktioniert ohne Problem. Eine weiterführende Integration von Web-
253
Kapitel 7 Ausblick
query in DIONE wäre aus ästhetischen Gründen wünschenswert und würde
auch die Benutzerfreundlichkeit erhöhen.
Sortieren nach bestimmten Tabellenspalten ermöglichen
Bisher ist es nicht möglich, Tabellen nach Spalten, die aus farbigen Blubbern
bestehen (z.B. Art der Nutzung von Trait-Matrix-Zeilen), zu sortieren.
Unabhängigkeit von biologischen Daten
Zurzeit ist DIONE in einigen Punkten, wie zum Beispiel beim Import von
Daten, noch nicht unabhängig vom LEDA-Projekt. Die Algorithmen können
jedoch auf für andere nicht biologische Daten verwendet werden. Daher wäre
eine noch flexiblerer Gestaltung der Daten- selektion eine positive Erweiterung.
Sequentieller Zugriff auf Daten
Zurzeit wird die gesamte Datenmenge einer Traitmatrix bei Gebrauch komplett in den Hauptspeicher geladen. Dies kann sich bei sehr großen Datenmengen negativ auf den benötigten Hauptspeicher auswirken. Deshalb
wäre ein sequentieller Zugriff auf die Zeilen einer Traitmatrix wünschenswert.
Dann würden zu einem Zeitpunkt nur die benötigten Zeilen im Hauptspeicher
gehalten werden. Auf der anderen Seite würde sich der sequentielle Zugriff
negativ auf die Dauer auswirken, die für die Modellberechnung durch einen
Algorithmus beötigt wird. Außerdem sind zurzeit nicht alle verwendeten Algorithmen in der Lage die Daten sequentiell zu lesen, sondern benötigen beim
Start der Modellberechnung die gesamte Datenmenge.
Zusätzliche Algorithmen
Da gerade bei der Entwicklung darauf geachtet wurde, die Erweiterung der
Anwendung möglichst einfach zu gestalten, ist das Hinzufügen von zusätzlichen Data-Mining Algorithmen wünschenswert.
Mehrsprachigkeit
Aus zeitlichen Gründen wurde die deutschsprachige Version der Webseite
nicht mehr gepflegt und auf den neusten Stand gehalten. Eine Übersetzung
der Inhalte in mehreren Sprachen wäre eine sinnvolle Erweiterung.
Bearbeitung von Daten
Häufig sind die Daten, die für den Algorithmus zur Verfügung gestellt werden
sollen nicht vollständig oder bedürfen noch weiterer Bearbeitung (Aggregation). Diese Funktionalität wurde bereits in der frühen Entwicklungsphase
angedacht, jedoch aus zeitlichen Gründen nicht umgesetzt.
Export des Modells als PMML
Um die Modelle auch mit anderen Programmen nutzten zu können, wäre ein
Export eines erstellten Modells im PMML-Format (basiert auf dem XMLStandard) eine weitere interessante Funktionalität.
254
7.2 Bekannte Fehler
7.2 Bekannte Fehler
Nachträgliche Änderung von Konfigurationen und Verifikation /
Vorhersage
Wenn man eine Verifikation oder eine Verhersage eines Modellerstellungsexperimentes machen möchte, dann funktioniert dies nicht, wenn das zu verifizierende Experiment (die Quelle) geändert worden ist, ohne dieses erneut
durchzuführen, so dass Ergebnis, Daten und Konfiguration zueinanderpassen.
255
Anhang
Abkürzungsverzeichnis
API: Application Programming Interface
CORBA: Common Object Request Broker Architecture
DOM: Document Object Model
FK: Fremdschlüssel
HTML: Hyper Text Markup Language
HTTP: Hyper Text Transaction Protocol
IDL: Interface Definition Language
IIOP: Internet Inter Orb Protocol
IMAP4: Internet Mail Application Protocol
J2EE: Java 2 Enterprise Edition
J2ME: Java 2 Micro Edition
J2SE: Java 2 Standard Edition
JAAS: Java Authentication und Authorization Service
JDBC: Java Database Connectivity
JEB: Java Enterprise Beans
I
Kapitel 7 Ausblick
JMS: Java Message Service
JMX: Java Management Extensions
JNDI: Java Naming and Directory Interface
JTA: Java Transaction API
JTS: Java Transaction Service
PK: Primärschlüssel
POP3: Post Office Protocol
SAX: Simple API for XML
SMTP: Simple Mail Transfer Protocol
SOAP: Simple Object Access Protocol
RMI: Remote Method Invocation
RPC: Remote Procedure Calls
XML: Extended Markup Language
II
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30
2.31
LEDA Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . .
Literaturquellen in der Datenbank . . . . . . . . . . . . . . . .
LEDA Datenbankschema . . . . . . . . . . . . . . . . . . . . . .
LEDA Datenbankschema - Einteilung . . . . . . . . . . . . . . .
Entitätstypen ohne die Pflanzenmerkmale . . . . . . . . . . .
Entitätstypen zu Pflanzenfundort und Lebensraum . . . . . .
Beispiel für einen Entitätstyp eines Pflanzenmerkmals . . . . .
J2EE Architektur Diagramm . . . . . . . . . . . . . . . . . . .
Übersicht über den J2EE-Aufbau . . . . . . . . . . . . . . . .
Übersicht über den Aufbau des Tomcat-Servers . . . . . . . .
Struktur einer SOAP-Message ohne Attachment . . . . . . . .
Request-Handling in J2EE . . . . . . . . . . . . . . . . . . . .
Beispiel für den Ablauf einer Anfrage an den Tomcat-Server .
Model-View-Controller in Struts . . . . . . . . . . . . . . . . .
Die erzeugte HTML-Seite . . . . . . . . . . . . . . . . . . . .
Entscheidungstabelle für die Wetterdaten . . . . . . . . . . . .
Entscheidungsbaum für die Wetterdaten . . . . . . . . . . . .
Auswahl des Wurzelknoten . . . . . . . . . . . . . . . . . . . .
Auswahl des Tochterknoten . . . . . . . . . . . . . . . . . . .
Informationsmass . . . . . . . . . . . . . . . . . . . . . . . . .
Darstellung des Abdeckungsalgorithmus . . . . . . . . . . . .
Gegensandstabelle der Wetterdaten . . . . . . . . . . . . . . .
Subtree-Replacement . . . . . . . . . . . . . . . . . . . . . . .
Trainingsdatensätze . . . . . . . . . . . . . . . . . . . . . . . .
Trainingsdaten mit gefundener Gleichung . . . . . . . . . . . .
Verhalten auf Ausreißer . . . . . . . . . . . . . . . . . . . . .
Beispiele für logistische Regression . . . . . . . . . . . . . . .
Exponentialfunktion . . . . . . . . . . . . . . . . . . . . . . .
Auswirkung einer Erhöhung der exogenen Variable auf pi . . .
Beispiel für einen Modellbaum . . . . . . . . . . . . . . . . . .
Ein Beispiel für die Anwendung von k-means aus [Han01], S.350
8
10
11
12
13
14
15
32
33
36
42
43
44
46
54
58
59
63
64
65
66
68
71
74
75
76
79
81
82
88
96
III
Abbildungsverzeichnis
2.32 Ein Beispiel für die Anwendung von k-medoids aus [Han01],
S.352 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.33 Übersicht der hierarchischen Verfahren aus [Han01], S.355 . .
2.34 Beispieldaten zur Erzeugung des Dendogrammes aus [Sto97],
S.131 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.35 Dendogramm aus [Sto97], S.132 . . . . . . . . . . . . . . . . .
2.36 Beispiel eines divisiven Clustering aus [Wit01], S.232 . . . . .
2.37 Ein Beispiel für die Anwendung von CURE aus [Han01], S.360
2.38 Ein Beispiel für die Anwendung von DBSCAN aus [Han01],
S.364 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.39 Beispiel für eine objektorientierte Repräsentation . . . . . . .
2.40 Beispiel für eine OO-Repräsentation mit Gewichten und Distanzmaßen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.41 Beispiel einer Baumstruktur . . . . . . . . . . . . . . . . . . .
2.42 Graphenisomorphie . . . . . . . . . . . . . . . . . . . . . . . .
2.43 Mögliche Nutzung des fallbasierten Schließens . . . . . . . . .
2.44 listentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.45 Die Arbeitsoberfläche . . . . . . . . . . . . . . . . . . . . . . .
2.46 Der Expression-Builder . . . . . . . . . . . . . . . . . . . . . .
2.47 Patientenkartei . . . . . . . . . . . . . . . . . . . . . . . . . .
2.48 Medikamentenverteilung . . . . . . . . . . . . . . . . . . . . .
2.49 Verhältnis von Na zu K . . . . . . . . . . . . . . . . . . . . . .
2.50 Textuelle Baumdarstellung des Ergebnis . . . . . . . . . . . .
2.51 Screenshot des fertigen Stream . . . . . . . . . . . . . . . . . .
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
98
99
100
102
103
104
109
115
115
116
117
119
123
128
129
130
131
132
133
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Wesentliche Anwendungsfälle . . .
Die weiteren Anwendungsfälle . . .
Prozessverlauf Übersicht . . . . . .
Prozessverlauf für Verfahren . . . .
Prozessverlauf Trait-Matrix . . . .
Prozessverlauf für Ergebnisvergleich
Aufbau des Systems . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
139
141
142
143
144
149
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Systemüberblick der einzelnen Modulen . . . . . . . . .
Schnittstelle zum Jobmanagement . . . . . . . . . . . .
Grobentwurf der Seitengestaltung . . . . . . . . . . . .
Schnittstelle zu Xelopes . . . . . . . . . . . . . . . . .
Schnittstellen WebUserInterface - Algorithmen . . . . .
Klasse des interaktiven Entscheidungsbaumalgorithmus
DAO-Schema . . . . . . . . . . . . . . . . . . . . . . .
DAO-Factory 1 . . . . . . . . . . . . . . . . . . . . . .
DAO-Factory 2 . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
153
155
156
159
160
160
161
162
163
Abbildungsverzeichnis
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
Paketstruktur des Java-Quelltextes . . . . . . . . . . . . . . .
Schnittstellen zur Kommunikation der einzelnen Module von
DIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DIONE Login-Seite . . . . . . . . . . . . . . . . . . . . . . . .
überblick über den Aufbau einer typischen DIONE-Webseite. .
Navigationselement der DIONE-Webseite. . . . . . . . . . . .
Die Kopfleiste der DIONE-Webapplikation . . . . . . . . . . .
Statusbox, die den Status der laufenden eigenen Experimente
zeigt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das Ergebnis eines Clustering Experiment . . . . . . . . . . .
Das Ergebnis eines Entscheidungsbaum Experiment . . . . . .
Überblick über die öffentlichen Experimente. . . . . . . . . . .
Struktur der Webordners von DIONE . . . . . . . . . . . . . .
Paketstruktur des Java-Quelltextes . . . . . . . . . . . . . . .
Klassendiagramm zum Modul Steuerung . . . . . . . . . . . .
Struktur des Paketes algorithm . . . . . . . . . . . . . . . . .
Struktur des Paketes algorithm.model . . . . . . . . . . . . . .
Struktur des Paketes algorithm.model.dione . . . . . . . . . .
Struktur des Paketes algorithm.util . . . . . . . . . . . . . . .
Klassendiagramm AttributeDescription . . . . . . . . . . . . .
Klassendiagramm Traitmatrix . . . . . . . . . . . . . . . . . .
Klassendiagramm DataImport . . . . . . . . . . . . . . . . . .
Klassendiagramm DataExport . . . . . . . . . . . . . . . . . .
Klassendiagramm WebQueryConstants . . . . . . . . . . . . .
Tabellenstruktur Algorithmusspezifikationen . . . . . . . . . .
Sequenzdiagramm zum Aufruf des Interaktiven Entscheidungsbaumalgoritmus (IEBA) . . . . . . . . . . . . . . . . . . . . .
177
178
184
185
185
186
186
188
189
190
191
195
201
206
208
212
213
224
226
227
227
229
238
247
V
Abbildungsverzeichnis
VI
Literaturverzeichnis
[1] http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf.
[2] Richtlinie 92/43/ewg des rates zur erhaltung der natürlichen lebensräume sowie der wildlebenden tiere und pflanzen (habitats directive), 1992. http://europa.eu.int/comm/environment/nature/
habdirde.htm.
[3] Cordis - entwicklungs- und informationsdienst der europäischen gemeinschaften, 2004. http://www.cordis.lu/de/home.html.
[4] Datenbankschema des leda-traitbase-projekts, 2004.
leda-traitbase.org/LEDAschema/.
http://www.
[5] Internet-homepage des leda-traitbase-projekts, 2004.
leda-traitbase.org/.
http://www.
[6] Un-konferenz für umwelt und entwicklung, rio de janeiro 1992, 2004.
http://www.biodiv.org/default.aspx.
[7] http://www.net-lexikon.de/J2EE.html. 2004.
[8] P. et al Atzeni. Database Systems – Concepts, Languages and Architectures. McGraw-Hill.
[9] M. Hall. Core Servlets und Java Server Pages.
München, 2001.
Markt+Technik,
[10] http://jakarta.apache.org/struts. The apache struts web application
framework. 2004.
[11] http://sourceforge.net/projects/easystruts. Easy struts plugin. 2004.
[12] http://www.coreservlets.com/Apache Struts-Tutor. A quick start tutorial for jakarta struts. 2004.
[13] SOAP in Netscape Gecko-based Browsers. http://devedge.netscape.
com/viewsource/2003/soap/01/. 2004.
VII
Literaturverzeichnis
[14] I.C. Knevel. Collecting and measuring standards of life-history traits of
the northwest european flora, 2004.
[15] Pascal Kuhn. Ausarbeitung zum Seminar: J2EE, Servlets und JSP.
2004.
[16] Net-Lexikon. http://www.net-lexikon.de. 2004.
[17] T. Reenskaug. Thing-model-view-editor, an example from a planningsystem, xerox parc technical note. 1979.
[18] T. Reenskaug. The model-view-controller. its past and present. jaoo
2003. 2003.
[19] M. et al Stadler. A common data standard for life-history traits of the
northwest european flora, 2003.
[20] C. Crawford und J. Kaplan. J2EE Design Patterns. O’Reilly, USA,
2003.
[21] R. Haas und U. Schreiner. Java- Technologien für Unternehmensanwendungen. München, 2002.
[22] Seminarvortrag: JAXR und WSDL.
http://www2.informatik.
uni-wuerzburg.de/mitarbeiter/eichelberger/deepJava2002/
JAXR+WSDL/ausarbeitung.pdf. Jan Junker, 2002.
[23] Wikipedia. http://de.wikipedia.org. 2004.
VIII

Zugehörige Unterlagen

Wir haben drei Abbildungen für Wahrheitswerte wahr (w) und falsch

DIONE Abschlussbericht 7. April 2005

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können