als PDF-Dokument - Informationssysteme

Transcription

Ableitung einer spezifischen Architektur aus
der Konzeption eines Ausführungsmodelles
für ReKlaMe-DDM-Analysen:
ReDi-CAt
ReKlaMe Distributed Classification Architecture
Diplomarbeit
Ralph Stuber
Carl von Ossietzky
Universität Oldenburg
FAKULT ÄT 2
D EPARTMENT
F ÜR I NFORMATIK
A BTEILUNG I NFORMATIONSSYSTEME
Diplomarbeit
Ableitung einer spezifischen Architektur aus
der Konzeption eines Ausführungsmodelles
für ReKlaMe-DDM-Analysen
vorgelegt von:
Ralph Stuber
Erstgutachter: Prof. Dr. H.-J. Appelrath
Zweitgutachter: Dr. Frank Köster
Betreuer: Dipl.-Inform. Heiko Tapken
Oldenburg, den 25. Februar 2005
Danksagung
Mein Dank gilt allen Menschen, die mit dazu beigetragen haben, dass ich diese Arbeit erstellen
konnte.
Allen voran danke ich zunächst meinen Eltern Christiane und Lothar Stuber, die mir das Studium ermöglicht haben, indem sie mir über die Jahre des Studiums die notwendige finanzielle
Grundlage geschaffen haben.
Weiter danke ich Aletta Kuper für das Verständnis und die Unterstützung in für mich arbeitsreichen Perioden sowie für den unermüdlichen Einsatz im Rahmen des Korrekturlesens.
Bezüglich der inhaltlichen Aspekte danke ich Matthias Pretzer, der trotz eigener Belastung
durch seine Diplomarbeit immer ein offenes Ohr für inhaltliche Belange meiner Arbeit hatte
und sinnvolle Ratschläge bezüglich aufkommender Fragestellungen beisteuern konnte.
Ich danke Michael Onken für seinen Einsatz im Hinblick auf ein sehr konstruktives, inhaltliches
Korrekturlesen.
Mein großer Dank gilt Heiko Tapken, der sowohl im Rahmen von Lehrveranstaltungen als auch
in Bezug auf diese Arbeit großen Einfluss auf mein Hauptstudium nahm. Das Thema dieser
Arbeit wurde gemeinsam mit ihm entwickelt und ist in sein Dissertationsvorhaben eingebettet.
Die Betreuung der Arbeit durch ihn war stets als ausgezeichnet zu bezeichnen.
Schließlich danke ich allen Personen, mit denen ich während meines Studiums zusammenarbeiten durfte, sei es im Rahmen von Übungsgruppen oder Klausur- und Prüfungsvorbereitungen.
Besonders seien hier Christian Lüpkes und Carsten Saathoff, und erneut Matthias Pretzer und
Michael Onken genannt.
Inhaltsverzeichnis
1. Einführung und Gliederung
1.1. Überblick ReKlaMe . . . . . . . .
1.2. Einführung in ein Beispielszenario
1.3. Ziele dieser Arbeit . . . . . . . .
1.4. Gliederung dieser Arbeit . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
4
5
5
2. Einführung in Distributed Data Mining (DDM)
2.1. Grundlagen des Distributed Data Mining . . . . . . . . . . . . . . .
2.1.1. Knowledge Discovery in Databases (KDD) . . . . . . . . .
2.1.2. Data Mining . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3. Klassifikation und Entscheidungsbäume . . . . . . . . . . .
2.1.4. Komponenten einer einfachen Data Mining-Architektur . .
2.2. Distributed Data Mining . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Was ist DDM? . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. Task-Parallelisierung als Herangehensweise an DDM . . . .
2.2.3. Daten-Parallelisierung als Herangehensweise an DDM . . .
2.2.4. Entscheidungsbauminduktion auf verteilten Datenbeständen
2.3. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
10
11
15
16
16
17
18
19
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Architekturen
23
3.1. Was ist eine Software-Architektur? . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1. Vorteile der Verwendung eines Architektur-Ansatzes . . . . . . . . . . 24
3.1.2. Der Design-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Überblick über verschiedene komponentenbasierte Architekturen . . . . . . . . 26
3.2.1. Architektur-Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. Architektur-Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Bewertungen der vorgestellten Architektur-Konzepte und -Ansätze im Kontext dieser Arbeit 33
3.3.1. Agentenbasierte Architekturen . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2. Mediator-Wrapper-Architekturen . . . . . . . . . . . . . . . . . . . . 34
3.3.3. Web-Service-Architekturen . . . . . . . . . . . . . . . . . . . . . . . 35
3.4. Fazit der Bewertungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5. J2EE und EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.1. Grundlegende Begriffsklärungen . . . . . . . . . . . . . . . . . . . . . 37
3.5.2. Die EJB-Architektur: Einordnung und Übersicht . . . . . . . . . . . . 38
3.5.3. Komponenten der EJB-Architektur . . . . . . . . . . . . . . . . . . . 39
3.5.4. Implementierung und Verwendung einer Bean . . . . . . . . . . . . . . 44
3.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4. Ein Ausführungsmodell für ReKlaMe-Analysen
4.1. ReKlaMe revisited - Zielsetzungen, Umgebung, Rahmenbedingungen
4.2. Abläufe und Phasen einer ReKlaMe-Analyse . . . . . . . . . . . . .
4.2.1. Grundsätzliche Betrachtungen . . . . . . . . . . . . . . . . .
4.2.2. Identifikation der Abläufe und Phasen . . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
48
48
50
ii
I NHALTSVERZEICHNIS
4.3. Beschreibung der Operatoren und Signaturen . . . . . . . . . . . . . . . . . . 54
4.3.1. Operatoren für die Induktion eines Klassifikators auf verteilten Datenquellen 56
4.3.2. Operatoren für die Anwendung eines Klassifikators auf verteilten Datenquellen 58
4.3.3. Operatoren für die Wartung von Klassifikatoren . . . . . . . . . . . . . 60
4.4. Operationalisierte Beschreibung der einzelnen Abläufe und Phasen . . . . . . . 62
4.4.1. Operationalisierte Beschreibung der Klassifikator-Induktion . . . . . . 62
4.4.2. Operationalisierte Beschreibung der Klassifikator-Anwendung . . . . . 66
4.4.3. Operationalisierte Beschreibung der Klassifikator-Wartung . . . . . . . 68
5. Architekturentwurf
73
5.1. Ableitung einer Architektur aus dem Ausführungsmodell . . . . . . . . . . . . 73
5.1.1. Architektur zur Induktion von Klassifikatoren . . . . . . . . . . . . . . 76
5.1.2. Architektur zur Anwendung von Klassifikatoren . . . . . . . . . . . . 79
5.1.3. Architektur zur Wartung von Klassifikatoren . . . . . . . . . . . . . . 82
5.1.4. Zusammenführung der Architekturen zur Induktion, Anwendung und Wartung 84
5.2. Erweiterung der Gesamt-Architektur um den Aspekt der Verteiltheit der Komponenten 85
6. Softwaretechnischer Entwurf des ReDiCAt Systemes
87
6.1. Objektorientiertes Design der Metadatenformate . . . . . . . . . . . . . . . . . 87
6.1.1. Interfaces und prototypische Implementierungen der abstrakten Datentypen 88
6.1.2. Interfaces und prototypische Implementierungen zur Repräsentation der Kontrollflüsse112
6.1.3. Interfaces und prototypische Implementierungen zur Parametrisierung der Analyse-Algorithm
6.2. Objektorientiertes Design der Komponenten der Architektur . . . . . . . . . . 134
6.3. Beschreibung der Methodenaufrufe zur Durchführung der Analyse-Abläufe . . 140
6.3.1. Ablauf der einfachen und inkrementellen Klassifikator-Induktion . . . . 140
6.3.2. Ablauf des Meta-Lernens . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.3.3. Ablauf der naiven Klassifikator-Anwendung . . . . . . . . . . . . . . . 146
6.3.4. Ablauf der Klassifikation mittels Selection Graphs . . . . . . . . . . . 149
6.3.5. Ablauf der Wartung eines inkrementell induzierten Klassifikators . . . 152
7. Implementierung und Test
157
7.1. Beschreibung des Referenzsystemes der Implementierung und des Tests . . . . 157
7.2. Prototypische Implementierung der Architektur . . . . . . . . . . . . . . . . . 157
7.3. Testszenarien und Testläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.3.1. Test der Abläufe der einfachen und inkrementellen Klassifikator-Induktion 160
7.3.2. Test des Ablaufes eines Meta-Lern-Vorganges . . . . . . . . . . . . . . 164
7.3.3. Test der Abläufe der Klassifikator-Anwendungen . . . . . . . . . . . . 165
7.3.4. Test des Ablaufes der Klassifikator-Wartung . . . . . . . . . . . . . . . 167
7.3.5. Zusammenfassung der Testläufe . . . . . . . . . . . . . . . . . . . . . 168
7.4. Vorzüge und Einschränkungen der prototypischen Implementierung . . . . . . 168
8. Zusammenfassung und Ausblick
171
8.1. Ergebnisse der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Anhang
175
ii
I NHALTSVERZEICHNIS
III
A. Detaillierte Darstellung der Bestandteile von Enterprise-Beans
177
A.1. Interfaces und Klassen zur Definition der GU-SB . . . . . . . . . . . . . . . . 177
A.2. Interfaces und Klassen zur Definition der MVSK-MDB . . . . . . . . . . . . . 181
A.3. Interfaces und Klassen zur Definition der MetadataRepository-EB . . . . 185
B. Installation und Nutzung von Enterprise-Beans
193
B.1. Packen und Installieren der Enterprise-Beans . . . . . . . . . . . . . . . . . . 193
B.2. Nutzung einer Bean durch einen Client . . . . . . . . . . . . . . . . . . . . . . 194
C. Ausgaben der Testläufe
C.1. Ausgaben des Analyse-Testlaufes zur einfachen Klassifikator-Induktion . . .
C.2. Ausgaben des Analyse-Testlaufes zur inkrementellen Klassifikator-Induktion
C.3. Ausgaben des Analyse-Testlaufes eines Meta-Lern-Vorganges . . . . . . . .
C.4. Ausgaben des Analyse-Testlaufes einer naiven Klassifikator-Anwendung . . .
C.5. Ausgaben des Analyse-Testlaufes der SG-Klassifikation . . . . . . . . . . . .
C.6. Ausgaben des Analyse-Testlaufes einer Klassifikator-Wartung . . . . . . . .
.
.
.
.
.
.
195
195
197
199
201
204
206
Glossar
209
Tabellenverzeichnis
212
Abbildungsverzeichnis
214
Symbolverzeichnis
217
Abkürzungsverzeichnis
219
Listing-Verzeichnis
222
Index
225
Literaturverzeichnis
228
iii
1. Einführung und Gliederung
Die von Unternehmen gespeicherten Datenvolumina steigen kontinuierlich an, da heutzutage
in fast allen Bereichen der Geschäftsabläufe eines Unternehmens Daten anfallen. Dabei ist ein
Trend zu beobachten, demzufolge die Datenmengen in den letzten Jahren um ein Vielfaches
gestiegen sind [FPSS96b, TG00]. Und auch für die Zukunft wird diesbezüglich ein ähnliches
Verhalten vorhergesagt [FPSS96b].
Derartige Daten können zu Analysezwecken gespeichert werden, um Wissen aus den Daten der
Geschäftsvorgänge generieren zu können. Dabei ist es einerseits wünschenswert, viele Daten
zu sammeln, um im Prozess der Wissensgewinnung möglichst genaue Ergebnisse zu erzielen.
So ist zu beobachten, dass Ergebnisse, die auf größeren Mengen von Trainingsdaten basieren,
auch genauer sind als solche, die aus geringeren Mengen von Daten erzeugt wurden [JC99].
Andererseits bedeutet eine Steigerung der Menge der Eingabedaten auch eine Erhöhung der
Kosten und der Ausführungszeiten der Analysen. Zudem existieren für die Analysealgorithmen Grenzen bezüglich der Menge der Eingabedaten, mittels derer Wissen aus Daten von
Geschäftsprozessen generiert werden kann. Die Menge der Eingabedaten, die ein Analysealgorithmus verarbeiten kann, hängt unter anderem von der Rechnerarchitektur ab, auf der die
Berechnungen ausgeführt werden. Einschränkende Kriterien sind hier der Arbeits- und der
Festspeicher sowie die Rechenleistung der Prozessoren.
Weiterhin ist zu beobachten, dass große Unternehmen oftmals nicht regional, sondern überregional oder global agieren, so dass die durch Geschäftsprozesse erzeugten Daten an verschiedenen Orten anfallen und auch getrennt voneinander gespeichert werden. Somit sind viele Datenbestände über mehrere, voneinander zu unterscheidende Datenbanken an mehreren
Orten verteilt. Durch potentiell unterschiedliche Geschäftsprozesse an unterschiedlichen Orten können die anfallenden Daten auch bezüglich ihrer Domäne differieren. Somit können sich
auch die Schemata, in denen die Daten gespeichert werden, voneinander unterscheiden, so dass
man von heterogenen Datenbeständen innerhalb eines Unternehmens sprechen kann.
Eine weitere Motivation für verteilte, voneinander getrennte und heterogene Datenbestände ist
in Datenschutzrichtlinien zu finden. So kann eine getrennte Datenhaltung eingesetzt werden,
die es Mitarbeitern unterschiedlicher Filialen eines Unternehmens unmöglich macht, Daten von
Geschäftsprozessen anderer Filialen einzusehen. Auch geschäftliche oder gesetzliche Gründe
können die Verteilung der Datenbestände auf verschiedene Orte motivieren [PCS00].
Ein Ansatz zur Lösung des Problems der verteilten Datenbestände liegt in der Zusammenführung dieser zu einem homogenen, einheitlichen Datenbestand. Es kann jedoch unter
Umständen undurchführbar sein, getrennt voneinander gehaltene, verteilte Datenbestände in
einen zentralen Datenbestand zu integrieren. Gründe hierfür liegen einerseits in datenschutzrechtlichen Aspekten, andererseits jedoch auch im Rechen-, Kosten- und Speicherungsaufwand
für die Zusammenführung der Daten in ein zentrales, homogenes Schema. Datentransfer von
verschiedenen, verteilten Datenbeständen beinhaltet finanziellen und zeitlichen Aufwand. Zudem entstehen Redundanzen im Bestand der gespeicherten Daten [TG00]. Letztlich kann es
einzig aufgrund des hohen Datenvolumens undurchführbar sein, verschiedene Datenbestände
zu homogenisieren und in einem zentralen Bestand zu speichern. Man stelle sich hier beispielsweise die Zusammenführung aller Daten des World Wide Web (WWW), welches den größten
1
2
K APITEL 1 - E INF ÜHRUNG UND G LIEDERUNG
existierenden, verteilten Datenbestand darstellt, als nahezu unerschöpflichen Eingabedatenbestand einer Analyse vor.
Sowohl die Durchführung von Analysen auf sehr großen Datenbeständen als auch die
Durchführung von Analysen auf heterogenen, verteilten Datenbeständen motivieren das sog.
Distributed Data Mining (DDM) (siehe Kapitel 2). Die Analyseprozesse, die während der Data Mining (DM) -Phase im Prozess des Knowledge Discovery in Databases (KDD) ausgeführt
werden, sind leicht parallelisierbar. Somit ließen sich Analyseschritte unter Nutzung monolithischer Basisdaten parallel durchführen, was größere Mengen von Eingabedatensätzen zuließe
und zudem auf verteilten Datenbanken ausgeführt werden könnte [Pro00]. Um dies zu ermöglichen, lassen sich Partitionierungsverfahren anwenden, die monolithische Datenbestände in
kleinere Partitionen aufteilen, die ihrerseits dann von verschiedenen Systemen gegebenenfalls
parallel analysiert werden können [GS00]. Im Falle einer gegebenen Verteilung der Eingabedaten ist dieser Partitionierungsschritt nicht notwendig, da die Basisdaten schon im Vorfeld
partitioniert an unterschiedlichen Orten vorliegen.
Distributed Data Mining eignet sich also zur Analyse von verteilten, großen Datenbeständen
aufgrund der Parallelisierung der Analyseschritte, die einerseits eine Geschwindigkeitssteigerung der Analyseläufe im Vergleich zum sequentiellen Berechnen der Analysen darstellt und
andererseits keine Kommunikation großer Datenbestände erfordert, da die Analysen auf den
verteilten Datenbeständen vor Ort parallel durchgeführt werden. Deren Ergebnisse können anschließend an eine zentrale Instanz, einen sog. Meta-Lerner, kommuniziert werden, der die einzelnen Teilergebnisse dann zu einem Gesamtmuster zusammenführt [Dit97], [GS00]. Um auf
das Beispiel der automatisierten Wissensgenerierung aus Datenbeständen des WWW zurückzukommen, könnten Software-Agenten in Zukunft auf diese Weise die verschiedenen Datenbestände des WWW analysieren und lediglich ihre Ergebnisse anstelle der zur Analyse notwendigen Basisdaten an einen Meta-Lerner kommunizieren, der diese dann in ein globales Muster
einpflegt. Somit wäre ein Schritt in Richtung der automatisierten Gewinnung von Wissen aus
den Datenbeständen des WWW getan.
Bei beiden vorgestellten Möglichkeiten der Verteiltheit von Daten (Verteiltheit durch Partitionierung, Verteiltheit aufgrund der Gegebenheiten) sind zwei Charakteristika erkennbar:
1. Es werden Informationen aus Teilen des gesamten Eingabedatenbestandes generiert.
2. Es wird aus den partiell erzeugten Ergebnissen ein globales Modell erzeugt.
Ein solches Vorgehen motiviert die Verfügbarkeit eines Systems, welches Analysealgorithmen
direkt auf den relationalen, verteilten Datenstrukturen anwenden und deren Analyseergebnisse
an einen Meta-Lerner weitergeben kann, der dann ein globales Modell erzeugt. Zudem sind
Anpassungen von vorhandenen Analyseverfahren an ein solches verteiltes Szenario notwendig.
1.1. Überblick ReKlaMe
Hier ansetzend wird das ReKlaMe-Projekt im Rahmen des Dissertationsvorhabens von Herrn
Heiko Tapken entwickelt. ReKlaMe steht für Klassifikation relationaler und verteilter Daten
am Beispiel des KundenmanageMents. Das Ziel des ReKlaMe-Projektes ist es, die erwähnten Einschränkungen der Verwendung verfügbarer Technologien bei direkter Anwendung auf
relationale Datensätze zu umgehen und somit die Induktion sowie die Anwendung dieser (beispielsweise Klassifikatoren) direkt auf den relationalen Teildaten zu ermöglichen [Tap04]. Somit bezieht ReKlaMe sich auf ein verteiltes Szenario, wie es im folgenden Abschnitt eingeführt
wird, jedoch im Speziellen auf Analyseverfahren der Klassifikation. In Abbildung 1.1 ist der
2
1.1 Ü BERBLICK R E K LA M E
3
Abbildung 1.1.: Analyse-Prozess im ReKlaMe-Ansatz [Tap04]
Analyse-Prozess im ReKlaMe-Projekt schematisch dargestellt. Daten können aus verteilten
Data Warehouses (DWH) (zu DWH siehe Abschnitt 2.1.4) extrahiert werden. Initiale lokale
Klassifikations-Algorithmen erlauben es, auf den relationalen Daten an den verteilten Standorten erste, nicht anonymisierte Wälder von Entscheidungsbäumen (siehe Abschnitt 2.1.3) auf
datenschutzrechtlich geschützter, privater Ebene zu generieren. In weiteren Schritten können
diese Entscheidungsbaumwälder durch Algorithmen zur Anonymisierung und durch Boostingalgorithmen aufgearbeitet und anschließend durch weitere, initiale Klassifikationsalgorithmen
auf datenschutzrechtlich ungeschützter, öffentlicher Ebene zu lokalen Modellen aufgearbeitet
werden. Als Ergebnis liegen anonymisierte und nicht anonymisierte, zu schützende Modelle lokal vor. Um die nichtanonymisierten Entscheidungsbaumwälder miteinander zu kombinieren,
werden auf datenschutzrechtlich geschützter, privater Ebene Kombinationsalgorithmen für homogene Modelle angewandt. Für die datenschutzrechtlich ungeschützten, öffentlichen Daten
kommen ebenfalls solche Kombinationsalgorithmen für homogene Modelle zur Anwendung.
So entstehen Entscheidungsbaum-Zwischenmodelle. Parallel dazu erzeugen sog. Grobkonzeptlerner Arbitrierungsregeln direkt aus den Daten der DWH. Über Arbitrierungsalgorithmen werden mittels dieser direkt gelernten Regeln und den erzeugten Zwischenmodellen globale Entscheidungsbäume generiert.
Um Entscheidungsbäume auf individuellen Datenwürfeln aus den DWH unter Berücksichtigung der Datenschutzaspekte induzieren zu können, wird ein modellgeführter InstanzauswahlAnsatz verfolgt. Dieser basiert auf der Hypothese, die vereinfacht besagt, dass im Falle, dass
3
4
eine Subdimension keinen besseren multivariaten Split liefert, keine Dimension besser geeignet ist. Dies gilt nur dann, wenn dass das Zielattribut aus Fakten zusammengesetzt ist.
Dieser Ansatz führt zu einer schnellen Restriktion des Suchraumes. So ist in jedem Schritt der
Entscheidungsbauminduktion eine optimale Splitfunktion erwünscht. Für jeden Datenwürfel
werden mehrere Hypothesen gelernt und dann unter Nutzung von Boosting-Techniken kombiniert.
1.2. Einführung in ein Beispielszenario
Anwendung finden diese Ansätze im Rahmen des ReKlaMe-Projektes in einem eigens dafür
aufgesetzten, exemplarischen Szenario aus der Domäne der Telekommunikationsbranche. Anhand dieses Szenarios soll eine verteilte Analyse umgesetzt und evaluiert werden.
Kern des Szenarios bildet ein überregional anbietender Telekommunikationsdienstleister, der
verschiedene Produkte zur Verfügung stellt. Ein solches Produkt besteht aus mehreren Komponenten; immer enthalten ist ein physischer Zugang zum Telekommunikationsnetz. Daran
gebunden können ein oder mehrere Tarife auf diesen Zugang gebucht werden. Die dazu notwendige Infrastruktur ist Eigentum des Telekommunikationsdienstleisters, jedoch kann dieser
auch Kapazitäten von anderen Dienstleistern hinzu mieten. Der überregionale Markt ist dem
Anbieter also bekannt, so dass dieser, je nach Bedarf, in speziellen Regionen Kapazitäten hinzu
mieten kann, um sein Angebot individuell auf regionale Bedürfnisse anzupassen.
Bezüglich der Kunden sind grundlegende demographische Daten bekannt, die bei Vertragsabschluss erhoben werden. Der Telekommunikationsdienstleister tritt bezüglich der erbrachten
Dienstleistung in Vorleistung, so werden die angebotenen Dienstleistungen erst im Nachhinein
in Rechnung gestellt, wie dies bei Telekommunikationsdienstleistungen üblich ist. Weitere Daten, die über den Kunden gespeichert werden, sind die Verbindungen, die dieser anwählt. Auf
Basis dieser Daten und der gewählten Tarifoptionen wird eine monatliche Rechnung erstellt.
Um sinnvolle Analysen und eine persistente, zeitbezogene Speicherung der Daten zu erreichen,
entschied die Geschäftsleitung, ein Data Warehouse einzurichten. Neben den verbindungsbezogenen Daten wird auch die überregionale Verteilung der Anschlüsse und speziell der Wandel
dieser Verteilung über die Zeit im Data Warehouse gespeichert.
Als Klassifikationsziel kann nun die Buchung bestimmter Produkte in bestimmten Regionen
gewählt werden. Hierbei könnten die Kundendaten mit berücksichtigt werden, um ein mögliches Profil darüber zu erstellen, welche Kundengruppe welche Produkte in welcher Region
bevorzugt. Anhand solcher Ergebnisse könnte dann eine gezielte Marketingkampagne gestartet und der Produktabsatz optimiert werden. Mittels dieser Analysen könnten auch Entscheidungen unterstützt werden, in welchen Regionen ein infrastruktureller Ausbau kommerziellen
Erfolg versprechen würde. Da ein Data Warehouse (siehe Abschnitt 2.1.4) die Daten zeitbezogen speichert, und auch Daten über beantragte, aktive, aktivierte, deaktivierte und gekündigte
Tarife und Tarifoptionen verfügbar sind, ließen sich auch Veränderungen in den Produktverbreitungen bezogen auf die Regionen durch Analysen erkennen, so dass auf Trends reagiert
werden könnte und Kunden gezielt beeinflusst werden könnten.
Ein weiteres Ziel einer möglichen Analyse könnte die Produktnutzung darstellen. Die Speicherung dieser Daten ist zur Rechnungsstellung ohnehin notwendig, so dass diese in das Data
Warehouse eingepflegt werden müssen. Wegen der Abrechnung und der daraus resultierenden
Notwendigkeit der genauen Erfassung haben diese Daten eine hohe Qualität und stellen eine sehr gute Grundlage für Analysen dar. Gespeichert werden die Dauer aller Verbindungen
pro Anschluss und die damit verbundenen Kosten, die sich aus Dauer und Art der Verbindung
4
1.3 Z IELE DIESER A RBEIT
5
berechnen lassen. Weiterhin werden die durchschnittliche Dauer eines Gespräches sowie der
durchschnittliche Umsatz pro Gespräch berechnet. Bezugspunkt für diese Werte ist eine festgelegte Zeitspanne, z.B. ein Kalendertag. Diese Gesprächsdaten können in Bezug zu Produkten,
Kunden oder Regionen gestellt werden. Die Kosten für die Nutzung eines Produktes hängen
auch von der Tageszeit ab, zu der dieses genutzt wird. So sind beispielsweise Gespräche nach
18 Uhr günstiger als in der Zeit von 8 bis 18 Uhr. Durch die Erfassung dieser Daten erhofft sich
die Geschäftsleitung, ein umfassendes Bild der Produktnutzung gewinnen zu können. So könnte festgestellt werden, welche Kundengruppe welche Produkte in welcher Region zu welcher
Zeit nutzt. Diese Erkenntnisse können eine Grundlage für Entscheidungen darstellen, welche
Produkte vermehrt beworben werden sollen bzw. in welchen Regionen sich ein Ausbau welcher
Produkte kommerziell lohnen könnte.
1.3. Ziele dieser Arbeit
Im Rahmen dieser Arbeit soll nach Schaffung der Wissensgrundlagen zunächst ein
Ausführungsmodell für Analysen im ReKlaMe-Kontext geschaffen werden. Das Ausführungsmodell soll umfassend spezifizieren, wie eine Analyse im ReKlaMe-Kontext genau verläuft
bzw. welche Alternativen sich bezüglich des Analyseverlaufes bieten. Dabei soll ein verteiltes
Szenario berücksichtigt werden, in dem die Datenbestände an unterschiedlichen Orten vorliegen und dort lokal analysiert werden sollen. Die Teilergebnisse der Analysen sollen dann an
zentraler Stelle von einem Meta-Lerner zu einem globalen Modell zusammengefügt werden.
Basierend auf dem Ausführungsmodell soll dann ein Architekturentwurf durchgeführt werden. Dieser Entwurf soll im Verlauf der Arbeit bezüglich noch zu identifizierender Kriterien
genau untersucht werden. Mögliche Kriterien für die genaue Untersuchung des ArchitekturKonzeptes sind hier z.B. Datenschutz-Aspekte oder die Unterstützung von Verteiltheit der
Komponenten. Auch der Aufwand der Einarbeitung in eine Technologie und die Komplexität
der Implementation ist bei der Untersuchung des Architektur-Konzeptes zu berücksichtigen.
Auf Basis der durchgeführten Arbeiten kann dann ein Softwaretechnischer Entwurf von ausgewählten Architekturaspekten erstellt werden, wobei die Komponenten der Architektur ebenfalls prototypisch implementiert werden. Auszuwählen sind in diesem Schritt mindestens die
Komponenten, die für das Ausführungsmodell bzw. dessen Steuerung benötigt werden.
Anschließend wird die Eignung der entworfenen Architektur anhand von verschiedenen Tests
validiert. Die Tests sollen die Funktionalität der im Ausführungsmodell beschriebenen Komponenten nachweisen und die möglichen Analyse-Vorgänge simulierbar implementieren.
Abschließend folgen eine kritische Untersuchung unter anderen Aspekten und eine genaue
Einschätzung der Eignung der ausgewählten Architektur.
1.4. Gliederung dieser Arbeit
In Kapitel 2 werden zunächst die Grundlagen des Distributed Data Mining (DDM) erläutert.
Anschließend gibt Kapitel 3 eine grobe Einführung in unterschiedliche Architektur-Ansätze.
Hierbei wird ein Architektur-Ansatz speziell betrachtet. Darauf folgend wird in Kapitel
4 ein Ausführungsmodell für das ReKlaMe-Szenario entworfen. Nach Entwicklung des
Ausführungsmodelles folgt in Kapitel 5 der Entwurf einer Architektur entsprechend der Anforderungen des Ausführungsmodelles anhand einer objektrientierten Analyse. Diese wird in
Kapitel 6 im Rahmen eines softwaretechnischen Entwurfes umgesetzt. In Kapitel 7 wird die
5
6
auf dem Entwurf basierende Implementierung detailliert vorgestellt. Schließlich werden in Kapitel 8 eine Zusammenfassung und ein Ausblick gegeben. Dabei werden die formulierten Ziele
dieser Arbeit aufgegriffen und anhand der durchgeführten Arbeiten und der dadurch gewonnenen Erkenntnisse auf korrekte Umsetzung bzw. Erreichung hin untersucht. Zudem werden
Ansatzpunkte für die weitere Entwicklung der im Rahmen dieser Arbeit entworfenen Architektur aufgeführt.
6
2. Einführung in Distributed Data Mining
(DDM)
Distributed Data Mining (DDM) bezeichnet einen Prozess, bei dem Data Mining auf verteilten
Datenquellen betrieben wird. Um diesen Prozess nachvollziehen zu können, bedarf es einiger
grundlegender Kenntnisse in den Bereichen Knowledge Discovery in Databases (KDD) und
Data Mining (DM). Daher werden in diesem Kapitel zunächst die Grundlagen erläutert, bevor
im Anschluss eine nähere Untersuchung des Distributed Data Mining durchgeführt wird.
Zunächst wird in Abschnitt 2.1.1 der Prozess des KDD eingeführt und erläutert. Anschließend
beschäftigt sich dieses Kapitel in Abschnitt 2.1.2 mit dem Data Mining, einem essentiellen
Schritt des KDD-Prozesses. Darauf folgend werden die Begriffe Klassifikation und Entscheidungsbaum in Abschnitt 2.1.3 eingeführt und anhand eines Beispieles veranschaulicht. Weiter wird ein Algorithmus zur Induktion eines Entscheidungsbaumes vorgestellt. Im Anschluss
wird in Abschnitt 2.1.4 ein Überblick über die typischen Komponenten einer Data MiningArchitektur gegeben.
Nachfolgend wird der Begriff des DDM in Abschnitt 2.2.1 eingeführt. In den Abschnitten
2.2.2 und 2.2.3 werden verschiedene Herangehensweisen an den Prozess des DDM diskutiert.
Schließlich wird im Abschnitt 2.2.4 die Erweiterung der Entscheidungsbauminduktion auf verteilte Szenarien betrachtet.
2.1. Grundlagen des Distributed Data Mining
Durch die großen Mengen an Daten, die heutzutage verfügbar sind, werden neben den Daten
über verwertbare, nützliche Informationen auch solche Daten gespeichert, deren Informationen
für eine weitere Verarbeitung nicht von Interesse sind. So ist es wünschenswert, einen automatisierten Prozess nutzen zu können, der die gehaltvollen, für potentielle Analysen notwendigen
und interessanten Daten von den uninteressanten Daten separiert und somit neues Wissen generiert. Dies ist der Ansatz des KDD.
2.1.1. Knowledge Discovery in Databases (KDD)
Der Begriff KDD steht für Knowledge Discovery in Databases und wird nach [FPSS96a] wie
folgt definiert:
Definition 2.1 Knowledge Discovery in Databases ist der nicht triviale Prozess der Identifikation valider, neuartiger, potentiell nützlicher und klar verständlicher Muster in Daten.
2
KDD ist als Prozess aufzufassen, der in verschiedene Schritte aufgeteilt ist. Es gibt viele unterschiedliche Modellvorschläge für den KDD-Prozess, die, bis auf eines, hier lediglich kurz
Erwähnung finden sollen. So zählen die Modelle nach Fayyad [FPSS96b], nach Brachman und
Anand [BA96] und nach Hippner und Wilde [HW01] sowie die Modelle SEMMA [SAS04]
7
8
K APITEL 2 - E INF ÜHRUNG IN D ISTRIBUTED D ATA M INING (DDM)
und CRISP-DM [CRI04] zu den am weitesten verbreiteten Modellen für den KDD-Prozess.
Für weitere Informationen über die aufgezählten KDD-Prozessmodelle sei hier auf [Zen03]
verwiesen.
Die einzelnen Modelle sind einander ähnlich, so dass es ausreichend ist, ein exemplarisches
Modell vertiefend vorzustellen. Zu diesem Zweck wird das Modell des KDD-Prozesses nach
Han und Kamber [HK00] gewählt, welches in Anlehnung an Fayyad [FPSS96b] aufgebaut ist
und in Abbildung 2.1 dargestellt wird. Dieses Modell wurde von Han und Kamber im Vergleich
zum Modell von Fayyad um ein Data Warehouse (DWH, siehe dazu Abschnitt 2.1.4) erweitert
und wird im Folgenden erläutert.
Abbildung 2.1.: Der KDD-Prozess (nach [HK00])
Im ersten Schritt des KDD-Prozesses nach [HK00] werden die Daten, die für die nachfolgenden Analysen von Interesse sind, aus verschiedenen Quelldatenbanken selektiert, extrahiert
und anschließend bereinigt. Dabei werden verschiedene Schritte zur Datenbereinigung, einem
Aspekt der Datenvorverarbeitung, durchgeführt, die in [Stu03], [Böh01] und [Zho02] näher
erläutert sind. An dieser Stelle soll nur kurz auf die Datenbereinigung eingegangen werden.
Damit Daten sich für die Verarbeitung im KDD-Prozess eignen, müssen diese bereinigt werden, da heterogene Daten Konfusionen verursachen, die zu unzuverlässigen und ungenauen Ergebnissen führen. Die folgenden Schritte werden während der Datenbereinigung durchgeführt:
• Fehlende Werte einzelner Attribute werden durch Standardbelegungen ersetzt oder mittels spezieller Werte als fehlend markiert
• Verrauschte Daten werden geglättet, um Ausreißer zu entfernen
• Inkonsistente Datensätze werden gelöscht, als inkonsistent markiert oder durch Anlegen
eines künstlichen Schlüsselattributes korrigiert
Der zweite Schritt des KDD-Prozesses ist die Datenintegration, ebenfalls ein Aspekt der Datenvorverarbeitung. Da die Daten aus den unterschiedlichen Datenquellen, wie z.B. Datenbanken oder flat files, in verschiedenen Schemata vorliegen, die oftmals heterogen sind, müssen
die Daten in ein gemeinsames, homogenes Schema integriert werden. So ist gewährleistet, dass
die Daten aus verschiedenen Quellen bei nachfolgenden Analysen in gleichem Aggregationszustand und in identischen Domänen vorliegen und somit die Qualität der Analysen steigt.
Die Datenintegration erfordert oftmals die Anpassung einzelner Daten, sei es, weil der Wertebereich differiert oder weil einfach syntaktische Unterschiede zwischen den zu vereinheitlichenden Datensätzen vorherrschen. Ein Beispiel für differierende Wertebereiche kann die
8
2.1 G RUNDLAGEN DES D ISTRIBUTED D ATA M INING
9
Angabe von Zeit in Stunden oder Minuten darstellen. So können beispielsweise in einem Datenbestand 2 Stunden als Dauer für eine Veranstaltung angegeben sein, wohingegen ein anderer
Datenbestand 120 Minuten für die identische Veranstaltung angeben kann. Unterschiedliche
syntaktische Darstellungen wie z.B. das Datum 2004-08-25 nach amerikanischer Norm, welches dem Datum 25. August 2004 nach deutscher Norm entspricht, sind hier ebenfalls denkbar.
Die vorverarbeiteten Daten werden anschließend in ein Data Warehouse geladen (zum Begriff
Data Warehouse siehe Abschnitt 2.1.4). Der Grund für die Durchführung einer Datenvorverarbeitung liegt darin, dass mit vorverarbeiteten Daten qualitativ hochwertigere Analyseergebnisse erzielt werden können. Kritisch zu betrachten ist bei der Datenvorverarbeitung und Datenbereinigung jedoch der Umstand, dass durch Datenbereinigung auch wertvolle Informationen
verloren gehen können. So deuten Ausreißerwerte (Werte, die weit außerhalb des durchschnittlichen Wertebereiches liegen) oftmals auf relevante Entwicklungen wie z.B. Kreditkartenbetrug
hin. Ausgehend von einem Kreditkartenkonto, von dem über einen langen Zeitraum nur kleine
Beträge transferiert wurden, kann die starke Nutzung innerhalb eines sehr kurzen Zeitraumes,
die als Ausreißer zu erkennen wäre, einen Betrugsverdacht nahe legen. Die Bereinigung solcher
Datensätze hätte ähnliche Folgen wie ein Datenverlust, da durch eine Bereinigung derartige
Entwicklungen in den Datensätzen verloren gingen.
Der dritte Schritt des KDD-Prozessmodelles nach [HK00] ist die Selektion. Hier werden die
Daten aus dem Data Warehouse selektiert, die den folgenden Analysen als Basis dienen. Der
Einsatz eines Data Warehouses wird von [HK00] vorgeschlagen, da die Daten dort bereits
bereinigt, aggregiert und integriert vorliegen. Dies erhöht einerseits die Qualität der Ergebnisse
einer Analyse, da diese von der Qualität der Eingabedaten abhängt, und reduziert andererseits
die Datenmenge, die der Analyse zugrunde liegt, da sie deren Kosten bestimmt und somit bei
der Kostenkalkulation mit zu berücksichtigen ist.
Nach der Selektion besteht der vierte Schritt in der Datentransformation, die dazu dient, die
Quelldaten in ein syntaktisch und semantisch korrektes Eingabeformat für die Analysealgorithmen zu bringen. Die Transformationsschritte beinhalten beispielsweise eine weitere Aggregation oder Summation einzelner Attribute, um diese auf die von den Algorithmen vorgegebenen
Wertebereiche zu transformieren oder weitere Datenreduktion zu betreiben. Für nähere Informationen sei hier auf [Stu03] verwiesen.
Im fünften Schritt des KDD-Prozesses wird Data Mining auf den vorverarbeiteten und selektierten Daten betrieben. Der Schritt des Data Mining wird in Abschnitt 2.1.2 ausführlicher
betrachtet. Vereinfacht dargestellt handelt es sich bei Data Mining um einen Analyseschritt,
der auf Basis einer Eingabedatenmenge Muster in den Daten findet und somit Information aus
Basisdaten generiert.
Die durch das Data Mining gefundenen Muster müssen anschließend im sechsten Schritt noch
evaluiert werden. Hier werden die tatsächlich interessanten, neu entdeckten Muster von denen
separiert, die für weitere Analysen oder Entscheidungen nicht von Interesse sind. Um dies
umzusetzen, ist Expertenwissen notwendig.
Abschließend wird das neu entdeckte bzw. generierte Wissen im siebten Schritt präsentiert,
indem Visualisierungs- und Wissensrepräsentationstechniken genutzt werden.
In allen Schritten des KDD-Prozesses hat der Anwender die Möglichkeit, interaktiv auf den
weiteren Verlauf der Analyseschritte Einfluss zu nehmen. So kann er bestimmen, welche Vorverarbeitungsschritte angewandt werden sollen. Auch bei der Integration der Datenbestände in
ein homogenes Schema kann der Anwender bestimmen, welche Attribute von einem Quell- in
ein Zielschema integriert werden. Bei der Selektion wählt der Anwender die für die nachfolgenden Analyseschritte notwendigen und wertvollen Daten aus. Der Anwender kann dahingehend
mit dem Schritt des Data Mining interagieren, indem er bestimmt, welche gefundenen Muster
9
10
von Interesse sind und als Wissen in die Wissensbasis eingehen sollen. Weiter kann er Einfluss
auf die Wahl geeigneter Analyseverfahren und deren Parametrisierung nehmen.
2.1.2. Data Mining
Nachdem die Daten im Prozess des KDD vorverarbeitet, selektiert und transformiert wurden,
wird, wie in Abschnitt 2.1.1 beschrieben, im fünften Schritt des KDD-Prozesses das Data
Mining durchgeführt. Das Data Mining ist ein essentieller Schritt im Prozess des KDD und ist
wie folgt definiert:
Definition 2.2 Data Mining umfasst die automatische Generierung von Modellen, die
maßgebliche Entwicklungen und Muster in Quelldaten beschreiben, durch intelligente Analysealgorithmen.
2
Die Aufgabe des Data Mining besteht darin, Informationen aus großen Mengen von Eingabedaten zu extrahieren. Durch Data Mining können Muster in Daten entdeckt werden, die zuvor
verborgen waren. Dabei kann der Schritt des Data Mining mit einem Benutzer oder einer Wissensbasis interagieren. So kann anhand dieser Interaktion eine Bewertung gefundener Muster
stattfinden, und davon abhängig eine Speicherung der gefundenen Muster als Wissen oder deren Verwerfung initiiert werden [HK00].
Typische Algorithmen, die während des Data Mining-Schrittes zum Einsatz kommen, sind
Algorithmen zum Clustering, zur Assoziationsanalyse und zur Klassifikation. Clustering und
Assoziationsanalyse werden im Anschluss definiert. Die Klassifikation wird in Abschnitt 2.1.3
ausführlich betrachtet, da sie im Kontext dieser Arbeit eine zentrale Bedeutung hat. Die Definition von Clustering nach [ES00] lautet wie folgt:
Definition 2.3 Clustering befasst sich mit dem Zusammenfassen von gleichartigen Daten zu Gruppen, indem Eingabedaten in Gruppen sich ähnelnder Objekte eingeteilt werden.
Dabei zeichnet einen Cluster aus, dass die darin enthaltenen Objekte zueinander eine hohe
und gegenüber Objekten anderer Cluster eine geringe Ähnlichkeit aufweisen.
2
Die Definition der Assoziationsanalyse ist an [HK00] angelehnt:
Definition 2.4 Die Assoziationsanalyse befasst sich mit der Identifikation von Objekten
innerhalb eines Datenbestandes, die in speziellen Beziehungen zueinander stehen.
2
Dabei wird unter einer speziellen Beziehung beispielsweise das ausschließlich paarweise Auftreten zweier Objekte innerhalb eines Datenbestandes verstanden. So könnte nach
Durchführung einer Assoziationsanalyse auf Datenbeständen eines Telekommunikationsunternehmens eine Assoziationsregel entdeckt werden, die besagt, dass ISDN-Kunden zu 80% auch
ein Produkt aus dem Portfolio der Internet-Produkte bestellen.
Weiterführende Informationen zum Thema Data Mining sowie nähere Informationen zu den
aufgeführten und zu weiteren Analysealgorithmen finden sich in [HK00].
Im folgenden Abschnitt erfolgt zunächst eine Definition der Begriffe Klassifikation und Entscheidungsbaum, dann folgt die Einordnung des Entscheidungsbaumkonzeptes in den Klassifikationskontext. Anschließend wird die Induktion eines Entscheidungsbaumes betrachtet.
10
11
2.1.3. Klassifikation und Entscheidungsbäume
Eine wichtige Technik der Analyse von Datenbeständen und der Generierung von Wissen aus
diesen ist die Klassifikation. Mittels der Klassifikation können Modelle induziert werden, die
wichtige Klassen von Daten beschreiben oder mittels derer Trends in Daten entdeckt werden
können. Anhand dieser Modelle ist es möglich, Daten bestimmten Klassen zuzuordnen.
Definition 2.5 Die Klassifikation ist ein Prozess, der aus zwei Schritten besteht. Im ersten
Schritt wird durch Analyse von Datentupeln, den Trainingsdaten, ein Modell induziert, das
eine vorgegebene Menge von Datenklassen oder Konzepten beschreibt. Im zweiten Schritt
wird das Modell genutzt, um Daten einer der gefundenen Klassen zuzuordnen.
2
Eine Methode der Klassifikation basiert auf Entscheidungsbäumen und wird im Folgenden
näher vorgestellt. Entscheidungsbäume eignen sich aufgrund ihrer hohen Klassifikationsgenauigkeit und aufgrund des Umstandes, dass sie bezüglich ihrer Semantik vergleichsweise leicht
zu interpretieren sind, gut für die Anwendung in der Klassifikation [MST94].
Definition Entscheidungsbaum
Ein Entscheidungsbaum ist eine Struktur zur Darstellung eines Klassifikators, die für eine spezielle Ausprägung einer Data Mining-Analyse, die Klassifikation, eingesetzt werden kann.
Definition 2.6 Ein Entscheidungsbaum ist eine azyklische, flußgraphähnliche Baumstruktur, die in ihren Knoten Attribute beinhaltet. Die von einem Knoten ausgehenden Kanten
beschreiben die möglichen alternativen Ergebnisse eines Tests auf diese Attributwerte. Die
Blätter stellen Zielklassen dar. Der in der Hierarchie am höchsten stehende Knoten wird als
Wurzel bezeichnet.
2
Ein Entscheidungsbaum kann zur Klassifizierung genutzt werden, indem die Attribute der zu
analysierenden Daten (Basisdaten) mit den in den einzelnen Knoten vorgehaltenen Attributen
verglichen und entsprechend dem Ergebnis des Vergleichs in eine Kindklasse dieser Knoten
eingeteilt werden.
Abbildung 2.2.: Ein beispielhafter Entscheidungsbaum (nach [HK00])
Beispielhafte Anwendung eines Entscheidungsbaumes
Ein Beispiel für einen Entscheidungsbaum ist in Abbildung 2.2 dargestellt. Dieser Entscheidungsbaum teilt Probanden in Abhängigkeit der Attribute Student mit den Ausprägungen
ja, nein und Bonität mit den Ausprägungen gut und mäßig in zwei Klassen ein, von
11
12
denen die eine Klasse die der potentiellen Kunden (mit dem Klassifikationsergebnis ja) und
die andere Klasse die der potentiellen Nichtkunden für einen DSL-Tarif eines Telekommunikationsanbieters (mit dem Klassifikationsergebnis nein) abbildet. Er repräsentiert somit das
Konzept DSL-Kunde. Jeder Knoten steht für den Test auf ein Attribut, jede Kante beschreibt
eines der möglichen Ergebnisse eines Testes und jedes Blatt repräsentiert eine Zielklasse, in
diesem Beispiel die Klasse der Käufer oder die der Nichtkäufer.
Eine beispielhafte Anwendung des Entscheidungsbaumes aus Abbildung 2.2 sei im Folgenden
aufgezeigt. Ein Proband, Student des Alters von 28 Jahren, soll anhand des Entscheidungsbaumes als potentieller Kunde oder als Nichtkunde für einen DSL-Tarif identifiziert werden.
Hierzu wird zunächst das Alter des Probanden getestet. Da dieser ein Alter von 28 Jahren
aufweist, wird als nächstes der Test auf Studentenstatus durchgeführt. Es wird also die Kante
des Baumes verfolgt, die mit dem Attributwert ≤30 beschriftet ist. Da der Status des Käufers
dem Attributwert Student entspricht, wird die mit ja beschriftete Kante verfolgt und der
Proband somit als potentieller Kunde für einen DSL-Tarif (mit der Klassenbezeichnung Ja)
klassifiziert.
In diesem Beispiel werden Studenten, deren Alter unter 30 Jahren liegt, Menschen des Alters
zwischen 31 und 40 Jahren sowie Menschen mit mäßiger Bonität, die zusätzlich nicht studieren
und ein Alter von über 40 Jahren aufweisen, als potentielle Kunden eines DSL-Tarifes klassifiziert. Alle anderen Menschen hingegen werden in die Klasse der potentiellen Nichtkunden
eingeordnet.
Anhand eines Entscheidungsbaumes können also unbekannte Entitäten anhand ihrer Attributwerte, die gegen den Entscheidungsbaum getestet werden, in Klassen mit spezifischen Eigenschaften eingeteilt werden. Ein von den Attributwerten der Entität abhängiger Weg durch den
Entscheidungsbaum bestimmt deren Klassenzugehörigkeit. Weiterhin können aus Entscheidungsbäumen auf einfache Art und Weise Klassifikationsregeln abgeleitet werden.
Um einen Entscheidungsbaum generieren zu können, bedarf es eines Induktionsalgorithmus.
Dieser wird im folgenden Abschnitt für nicht-verteilte und im Abschnitt 2.2.4 für verteilte
Szenarien näher betrachtet.
Nichtverteilte Induktion von Entscheidungsbäumen
In diesem Abschnitt wird der Entscheidungsbaum-Induktionsalgorithmus ID3 vorgestellt.
Dieser Algorithmus induziert einen Entscheidungsbaum in einer rekursiven top-downVorgehensweise. Die Induktion basiert auf gegebenen Trainingsdaten, deren Besonderheit darin besteht, dass sie bereits ein feststehendes Klassifikationsergebnis darstellen. Die Eingabe des
ID3-Algorithmus besteht aus diesen Trainingsdaten, die in Form von diskreten Attributen, den
Eingabedaten, vorliegen, und aus einer Menge von Attributen, die zu klassifizieren sind, der Attributliste. Als Ausgabe produziert ID3 einen Entscheidungsbaum. Die Strategie, nach der ein
Entscheidungsbaum induziert wird, ist in Algorithmus 1 grob skizziert und wird im Folgenden
ausführlich erläutert. Der Algorithmus ist an die Ausführungen aus [HK00] angelehnt.
Algorithmus zur Induktion eines Entscheidungsbaumes
Zur Verdeutlichung der Funktionalität des ID3-Algorithmus zur Entscheidungsbauminduktion
sind die Erläuterungen an die einzelnen Schritte des Algorithmus angelehnt. Diese Version des
ID3-Algorithmus erlaubt lediglich diskrete Eingabedatensätze.
Der Entscheidungsbaum startet als einzelner Knoten, der alle Eingabedaten repräsentiert (entsprechend Schritt 1 des Algorithmus). Wenn die Eingabedatensätze alle aus der selben Klasse
12
13
Algorithmus 1: ID3-Entscheidungsbaum-Induktionsalgorithmus
Algorithmus: Generate decision tree(Eingabedaten,Attributliste)
1. Erzeuge einen Knoten N ;
2. if (Eingabedaten gehören alle zu der selben Klasse C)
Gib N als Blatt zurück, welches mit der Klassenbezeichnung C versehen ist;
3. if (Liste der Attribute ist leer)
Gib N als Blatt zurück, welches mit der Klassenbezeichnung der Klasse aus den
Eingabedaten versehen wird, die am meisten Ähnlichkeiten in ihren
Eigenschaften aufweist;
4. Wähle Testattribute aus der Liste aller Attribute so, dass sie den höchsten Informationsgehalt aufweisen;
5. Benenne Knoten N mit Testattribut;
6. for each bekannten Wert aus den Testattributen;
a) Erzeuge für die Bedingung Testattribut = ai einen Ast von Knoten N ;
b) Sei Si die Menge der Datensätze in den Eingabedaten mit Testattribut = ai ;
c) if (Si ist leer)
Erzeuge ein Blatt mit Bezeichnung der ähnlichsten Klasse aus den
Eingabedaten und füge es an die Kante an;
d) else
Füge den durch den Aufruf von
Generate decision tree(Si ,{Attributliste −Testattribut})
erzeugten Knoten an die Kante an;
stammen, so wird aus dem Knoten ein Blatt, welches mit dem Namen der Klasse bezeichnet
wird (Schritt 2). Andernfalls nutzt der Algorithmus ein entropiebasiertes Maß, den information gain (engl. für Informationsgewinn“), als Heuristik, um zu entscheiden, welches Attribut
”
am besten dazu geeignet ist, die Eingabedatensätze voneinander in individuelle Klassen zu
separieren (Schritt 4). Dieses Attribut wird dann zum Testattribut, anhand dessen jedes Eingabedatum in diesem Knoten auf Wertausprägung getestet wird (Schritt 5). Für jeden Wert, den
dieses Attribut annehmen kann, wird eine Kante erzeugt, und die Eingabedatensätze werden
entsprechend partitioniert (Schritte 6a und 6b). Auf die selbe Weise nutzt der Algorithmus nun
die bereits beschriebenen Schritte, um für die neu erzeugten Partitionen von Eingabedaten rekursiv wiederum Entscheidungsbäume zu generieren, die an die erzeugten Kanten angehängt
werden. Ein Attribut, welches in einem Knoten auftritt, wird bei fortführenden Iterationen nicht
weiter betrachtet (Schritt 6d). Die rekursive Entscheidungsbauminduktion stoppt nur, falls eine
der folgenden Bedingungen wahr ist:
• Alle Eingabedaten für einen gegebenen Knoten gehören zur selben Klasse.
• Es gibt keine weiteren Attribute mehr, nach denen die Testdaten partitioniert werden
können. In diesem Fall wird aus dem Knoten ein Blatt, welches mit dem Namen der
13
14
Klasse bezeichnet wird, zu der die meisten Datensätze der Eingabedaten zugeordnet werden können (Schritt 3). Alternativ kann der Name der Klasse des Knotens als Name des
Blattes zugeordnet werden.
• Es gibt keine Datensätze in den Eingabedaten mehr, die auf ein Attribut getestet werden können. In diesem Fall wird ein Blatt erzeugt, welches mit dem Namen der Klasse
bezeichnet wird, zu der die meisten Datensätze der Eingabedaten zugeordnet werden
können (Schritt 6c).
Um entscheiden zu können, welches Attribut zur Basis der Attributwert-Untersuchungen in
einem Knoten herangezogen werden soll, wird ein Maß zur Attributauswahl benötigt.
Maß zur Attributselektion: Der information gain
Der information gain, der durch die Wahl eines Attributes erzielt werden kann, ist für die
Entscheidung, welches Attribut zur weiteren Attributwert-Untersuchung an einem Knoten herangezogen werden soll, von Interesse. Das Attribut, welches den höchsten Informationsgewinn
erbringt, wird als Testattribut für den aktuellen Knoten gewählt. Auf diese Weise soll erreicht
werden, dass die Anzahl von Attributtests minimiert und ein einfacher, aussagekräftiger Entscheidungsbaum generiert werden kann. Die Bestimmung eines Maßes zur Auswahl eines Attributes als Testattribut (nach [HK00]) sei im Folgenden formal aufgezeigt.
Sei S eine Menge, die aus Datensätzen s = {s1 , s2 , . . . , sn } besteht. Man nehme an, m sei
die Anzahl unterschiedlicher Werte, die m unterschiedliche Klassen Ci = {c1 , c2 , . . . , cm }
definiere. Sei Si die Menge der Datensätze aus S, die in der Klasse Ci enthalten sind. Die zu
erwartende Information I aus der Partitionierung der Trainingsdaten nach einem Attribut ergibt
sich aus folgender Gleichung:
I(s1 , s2 , . . . , sm ) =
m
X
pi log2 (pi ),
(2.1)
i=1
wobei pi die Wahrscheinlichkeit darstellt, dass ein willkürlicher Datensatz zur Klasse Ci gehört
und durch Ssi abgeschätzt wird. Je geringer der Wert von I ausfällt, umso besser ist die Partitionierung zu bewerten. Weiterhin zeigt ein geringer Wert von I, dass die Klassen besser voneinander getrennt sind, und somit lassen sich umso einfacher weitere Datensätze klassifizieren,
da zur Klassifizierung weniger Informationen benötigt werden.
Ein Attribut A weise nun v verschiedene Werte {a1 , a2 , . . . , av } auf. So kann A genutzt werden, um die Menge S in v Untermengen {S1 , S2 , . . . , Sv } zu partitionieren, wobei Sj die Eingabedatensätze aus S enthält, die den Wert aj aus A aufzeigen. Falls A als Testattribut bestimmt
wurde, dann entsprechen diese Untermengen den Kanten, die vom Knoten, der die Menge S
repräsentiert, ausgehend erzeugt werden. Sei dann Sij die Anzahl der Datensätze aus der Klasse Ci , die in einer Partition Sj von S enthalten sind. Die Entropie E, die benötigte Information
für eine Klassifikation eines Datensatzes anhand eines Entscheidungsbaumes, wird berechnet
durch
v
X
S1j + . . . + Smj
E(A) =
I(S1j , . . . , Smj ).
(2.2)
s
j=1
Je kleiner der Wert der Entropie, umso eindeutiger verläuft die Trennung zwischen den Klassen.
Die Auswahl des Attributes, welches den höchsten Informationsgewinn erbringt, basiert auf
dem information gain, der mittels folgender Gleichung ermittelt wird:
Gain(A) = I(s1 , s2 , . . . , sm ) − E(A).
14
(2.3)
15
Der information gain ist die Menge an Informationen, die durch die Partitionierung gewonnen wurde. Zurückkommend auf die Entscheidungsbauminduktion wird das Attribut mit dem
höchsten information gain als Testattribut für die Elemente der Klasse S gewählt. Nach Auswahl dieses Attributes wird ein Knoten generiert und mit dem Attribut beschriftet. Für jede
Ausprägung eines Wertes für das erwählte Attribut wird von dem neu generierten Knoten eine Kante erzeugt, die mit dem jeweiligen Attributwert beschriftet wird. Entsprechend dieser
Attributwerte werden die Trainingsdaten partitioniert.
Pruning von Entscheidungsbäumen
Wenn ein Entscheidungsbaum induziert wird, so erzeugen Ausreißer und Rauschen in den Trainingsdaten (engl. outliers und noisy data) Anomalien im Baum. Es kann beobachtet werden,
dass komplexere Entscheidungsbaumstrukturen häufig schlechtere Klassifikationsergebnisse
erzeugen als weniger komplexe Bäume. Dieses Phänomen wird mit dem Begriff overfitting
bezeichnet [Pre03]. Sog. pruning-Methoden wirken dem Problem des overfitting entgegen,
indem sie unter Nutzung von statistischen Methoden die wenig verlässlichen Äste des Entscheidungsbaumes entfernen, um so Klassifikationen zu beschleunigen und die Qualität der
Klassifikationsergebnisse zu verbessern.
2.1.4. Komponenten einer einfachen Data Mining-Architektur
Um Data Mining-Analysen durchführen zu können, wird eine Architektur benötigt, die die dazu notwendigen Komponenten bereitstellt. Die Komponenten einer solchen Architektur werden in diesem Abschnitt vorgestellt. In Anlehnung an [BG01] zählen zu einer einfachen Data
Mining-Architektur in der Regel verschiedene Komponenten. Die bedeutendsten seien im folgenden aufgeführt:
Data Warehouse Systeme (DWS) DWS stellen Data Warehouses bereit, um Daten für das
Data Mining in vorverarbeiteter Form zur Verfügung zu stellen. Ein Data Warehouse
(DWH) bezeichnet eine Sammlung von themenorientierten, integrierten, nichtflüchtigen
und zeitbeständigen Daten zur Unterstützung von Management-Entscheidungen in einem Unternehmen [BG01]. Ein Data Warehouse System (DWS) ist ein Informationssystem, welches alle für den DWH-Prozess benötigten Komponenten bereitstellt. Zu
diesen Komponenten zählen Datenbeschaffungsbereich und Analyse, Metadatenmanagement, DWH-Management und die Basisdatenbank, das eigentliche Data Warehouse
und das Repository. Die Gründe für das Betreiben eines DWS sind vielfältig, so zählen
u.a. ein besseres Antwortverhalten als das einer herkömmlichen Datenhaltung und eine
langfristige, zeitbehaftete Datenspeicherung, die die Durchführung von Analysen unter
Berücksichtigung zeitlicher Aspekte ermöglicht, zu den Vorteilen des Einsatzes eines
DWS. Weiter ist der Datenzugriff für die Analyse unabhängig von operativen Systemen,
da die Daten in einem DWH nicht die direkten Datenbestände der operativen Systeme,
sondern davon angefertigte Kopien darstellen. Die Repräsentation der Daten in einem
DWH ist homogen, und schließlich ist die Datenqualität bzgl. der Vorverarbeitungen
[Stu03] gewährleistet. Welche Daten als Grundlage der späteren Analyse dienen, wird
von dem Benutzer festgelegt, der die Analyse durchführt.
Wissensbasis Die Wissensbasis beinhaltet das Domänenwissen, welches auf vielfältige
Weise genutzt werden kann. So kann der Suche nach neuen Mustern oder der Evaluation
des Wertes gefundener Muster eine Metrik der Bedeutung zugrunde gelegt werden. Eine
Wissensbasis kann Konzepthierarchien beinhalten, um einzelne Attribute in verschiedenen Abstraktionsebenen einordnen zu können.
15
16
Data Mining Engine Die Data Mining Engine stellt verschiedene Komponenten zur
Verfügung, die die Analysefunktionalität bereitstellen. Typische Analyseverfahren des
Data Mining stellen die Charakterisierung, die Assoziationsanalyse, die Clusteranalyse
sowie die Entwicklungs- und Abweichungsanalyse dar.
Musterevaluationskomponente Die Musterevaluationskomponente stellt eine Metrik der
Interessantheit für die Bewertung gefundener Muster dar.
Benutzungsschnittstelle Eine Benutzungsschnittstelle soll die Kommunikation zwischen
den einzelnen Komponenten der Architektur und dem Benutzer, der eine Analyse
durchführen möchte, ermöglichen.
Mit Kenntnis über den Prozess des KDD, den Schritt des Data Mining, der Analysemethode
der Klassifikation unter Nutzung von Entscheidungsbäumen sowie deren Induktion auf nichtverteilten Datenquellen, sind die Grundlagen für die Einführung des Distributed Data Mining
geschaffen. Im folgenden Abschnitt werden nun die zuvor vorgestellten Konzepte erweitert auf
verteilte Szenarien betrachtet.
2.2. Distributed Data Mining
Aufgrund des Umstandes, dass Daten verteilt an unterschiedlichen Orten anfallen oder gehalten
werden, und mit Hinblick auf die Möglichkeiten, die eine Parallelisierung der Durchführung
von Analysen zur schnelleren Erzeugung von Ergebnissen bieten, entsteht der Bedarf nach
Technologien, um verteilte Analysen durchführen zu können. Jedoch sind die meisten Analysealgorithmen auf zentralisiert gehaltene Daten ausgelegt, so dass im Falle einer verteilten
Analyse eine Anpassung dieser erforderlich ist [KKC00].
In diesem Abschnitt findet zunächst eine nähere Untersuchung des DDM statt. So erfolgt eine
Klärung des Begriffes DDM. Anschließend werden zwei Herangehensweisen an DDM aufgezeigt: die der Task-Parallelisierung und die der Daten-Parallelisierung am Beispiel der Anwendung von Entscheidungsbäumen zur Klassifikation. Abschließend wird die Entscheidungsbauminduktion auf verteilte Szenarien erweitert.
2.2.1. Was ist DDM?
Zusammenfassend lassen sich die Hauptziele des DDM wie folgt formulieren:
Definition 2.7 Distributed Data Mining (DDM) umfasst die Entwicklung von Algorithmen, Systemen und Architekturen für eine Datenanalyse, die auf verteilten Systemen und auf
verteilten Datenquellen eingesetzt werden können.
2
Verschiedene Algorithmen sollen auf den verteilten Systemen ausführbar sein. Dabei spielen
auch Aspekte der Skalierbarkeit bezüglich großer Datenbestände und Anzahl der Datenquellen eine wichtige Rolle [KKC00]. DDM ist als Schritt des Distributed Knowledge Discovery
(DKD) aufzufassen [KC00].
Definition 2.8 Distributed Knowledge Discovery (DKD) befasst sich mit dem Ausführen
des KDD-Prozesses auf nicht zentralisierten Daten.
2
16
2.2 D ISTRIBUTED D ATA M INING
17
DDM basiert nicht mehr nur auf Berechnungen der Analysealgorithmen, wie es bei konventionellem Data Mining der Fall ist. Viel mehr umfasst DDM zusätzlich die Kommunikation, sei
es die der verteilt erzeugten Ergebnisse oder die zur Beschaffung gegebenenfalls heterogener
Daten aus verteilten Quellen. Eine Anforderung ist es hierbei, die Kommunikation möglichst
gering zu halten, um den Zeitbedarf der Durchführung von Analysen und damit deren Kosten
zu minimieren.
Auf einem herkömmlichen, nicht verteilten Data Mining-System kann eine parallele Analyse
wie in Abbildung 2.3 dargestellt ablaufen. Verschiedene Algorithmen arbeiten parallel innerhalb eines Systemkontextes auf potentiell allen verfügbaren Datenquellen.
Algorithmus 1
Daten 1
Algorithmus 2
Daten 2
Algorithmus 3
Daten 3
Abbildung 2.3.: Paralleles Data Mining auf einem einzelnen System (nach [Tal03])
In den beiden folgenden Abschnitten seien alternativ zum nicht verteilten Ansatz der Parallelausführung einer Analyse zwei Herangehensweisen an eine Parallelausführung einer Analyse
auf verteilten Systemen, einer Form von DDM, aufgezeigt: die Task-Parallelisierung und die
Daten-Parallelisierung. Anhand eines Beispieles werden die beiden Herangehensweisen genauer illustriert. Die Ausführungen lehnen sich dabei an [Tal03] an.
2.2.2. Task-Parallelisierung als Herangehensweise an DDM
Bei der Task-Parallelisierung wird der Ansatz verfolgt, dass verschiedene Prozesse auf (gegebenenfalls verschiedenen) Daten (eingeschränkt) zur selben Zeit Analysen ausführen. Diese
Prozesse seien in Abbildung 2.4 dargestellt und können auf verschiedene Systeme verteilt werden.
Algorithmus 1
Algorithmus 2
Daten 1
Daten 2
Daten 3
Prozess 1
Prozess 2
Prozess 0
Algorithmus 3
Abbildung 2.4.: Task-parallelisiertes DDM (nach [Tal03])
Es werden also die Analyseaufgaben verteilt, so dass unterschiedliche Systeme jeweils eine
spezielle Analyse ausführen können. Die Ergebnisse dieser Analysen können später wieder
zentral vereinigt und weiterverarbeitet werden.
Bezogen auf eine Analyse zur Klassifikation könnte eine beispielhafte Anwendung dieses Konzeptes wie folgt aussehen: in Abbildung 2.5 ist ein Entscheidungsbaum dargestellt, anhand
dessen eine Klassifikation durchgeführt werden kann. Jedem der drei dargestellten Teilbäume
(in Abbildung 2.5 durch eine farbige Fläche gekennzeichnet) kann nun ein Prozess zugeordnet
werden, der parallel zu den anderen Prozessen eine Klassifikation anhand seines Teilbaumes
17
18
Prozess 1
Prozess 3
Prozess 2
Abbildung 2.5.: Task-parallelisierte Klassifikation (nach [Tal03])
durchführen kann. Dazu benötigt er jedoch die erforderlichen Eingabedaten. In dem in Abbildung 2.5 dargestellten Fall kann beispielsweise Prozess 3 erst mit der Klassifizierung eines
Datensatzes starten, sobald Prozess 1 die Klassifizierung dieses Datensatzes abgeschlossen hat,
da erst dann dessen Zugehörigkeit zu einer Zielklasse von Prozess 1 identifiziert und somit als
mögliche Eingabe für Prozess 3 verfügbar ist, da dessen Wurzelknoten eine Zielklasse von Prozess 1 ist. Ein solcher Aufbau weist Parallelen zum sog. Pipelining (siehe dazu [Neb95]) auf,
auf das in dieser Arbeit nicht weiter eingegangen wird.
2.2.3. Daten-Parallelisierung als Herangehensweise an DDM
Bei der Daten-Parallelisierung werden die Daten partitioniert und auf verschiedene Systeme
verteilt. Dort arbeiten jeweils identische Prozesse auf disjunkten Teilpartitionen der Daten.
Dieses Vorgehen ist in Abbildung 2.6 beispielhaft dargestellt.
Algorithmus 1
Algorithmus 1
Algorithmus 1
Daten 11
Daten
Daten 11
Daten
Daten 1
Abbildung 2.6.: Daten-parallelisiertes DDM (nach [Tal03])
Die Prozesse können die partiell erzeugten Ergebnisse ebenfalls an zentraler Stelle vereinigen und weiterverarbeiten. Aufgrund der durch dieses Vorgehen ermöglichten Skalierbarkeit
der Analyseausführung können massive Performancegewinne erzielt werden. Zur Vereinigung
der Ergebnisse kommen sog. Metalerner zum Einsatz, deren Funktionalität in Abschnitt 2.2.4
erläutert wird.
Prozess 1
Prozess 2
Prozess 3
Abbildung 2.7.: Daten-parallelisierte Klassifikation (nach [Tal03])
In Abbildung 2.7 ist der Ansatz der Daten-Parallelisierung anhand des bereits zuvor verwendeten Beispieles für eine verteilte Klassifkation dargestellt. Die Menge der Eingabedaten wird
18
2.2 D ISTRIBUTED D ATA M INING
19
in n Untermengen aufgeteilt, wobei n der Anzahl der Prozesse entspricht, die parallel klassifizieren (dargestellt durch unterschiedlich eingefärbte Entscheidungsbäume, die je einem Prozess entsprechen). Jeder der drei im Beispiel aufgeführten Prozesse klassifziert die Daten einer
dieser Untermengen. Dabei können die Prozesse wieder verteilt auf verschiedenen Systemen
ausgeführt werden. Nachdem alle Prozesse alle Daten der von ihnen zu bearbeitenden Untermengen klassifziert haben, können die Ergebnisklassen vereinigt werden, um ein globales
Ergebnis zu erzielen (in der Abbildung durch die gestrichelten Bögen visualisiert).
Die zuvor dargestellten Ausführungen beziehen sich auf die Anwendung von Analysealgorithmen. Da die Klassifikation, wie bereits in Abschnitt 2.1.3 angeführt, zusätzlich zur Anwendung
auch die Erzeugung eines Klassifikators erfordert, wird im folgenden Abschnitt die Induktion
von Entscheidungsbäumen auf verteilte Szenarien erweitert.
2.2.4. Entscheidungsbauminduktion auf verteilten Datenbeständen
Soll ein Entscheidungsbaum nicht auf einem lokalen Datenbestand, sondern auf Daten in verschiedenen, auf mehrere Systeme verteilten Datenbeständen induziert werden, so können unterschiedliche Strategien verfolgt werden. In Abhängigkeit von dem gegebenen Anwendungsszenario sollte individuell die am besten geeignete Strategie verfolgt werden. Im Folgenden
sind mögliche Vorgehensweisen für verschiedene Einsatzgebiete aufgeführt.
Einfacher Ansatz: Zusammenführung der Datenbestände
Eine nahe liegende, bei geringen Datenbeständen effektive Methode sieht die Integration aller
verteilten Daten in einen Datenbestand vor, auf dem dann, wie in Abschnitt 2.1.3 beschrieben,
eine nichtverteilte Entscheidungsbauminduktion lokal durchgeführt werden kann. Durch die
Vereinigung zu einem Datenbestand werden die Daten redundant gehalten. Zudem müssen
sie kommuniziert werden, was zeitlichen und finanziellen Aufwand bringt sowie bezüglich
datenschutzrechtlicher Aspekte ein Risikopotential mit sich bringt. Weiterhin ist das Vorhaben,
Daten aus verschiedenen Quellen in ein gemeinsames Schema zu integrieren, nicht trivial und
möglicherweise mit viel zeitlichem und finanziellen Aufwand verbunden. Daher ist in einem
Szenario, welches große Datenmengen an verteilten Orten vorhält, eine alternative Lösung
wünschenswert, da diese Vorgehensweise mit steigenden Datenmengen stetig ineffektiver wird.
Alternativer Ansatz: Verteilung der Analysen
Eine Alternative für Szenarien, in denen große Datenbestände analysiert werden sollen, kann
in der Verteilung der Analysen bestehen. Ausgehend von einem Szenario, in dem verschiedene
Datenquellen an verteilten Orten analysiert werden sollen, können sog. Basisklassifikatoren
eingesetzt werden [PCS00].
Definition 2.9 Ein Basisklassifikator erzeugt auf den verteilten Datenbeständen nach
herkömmlichen Verfahren Entscheidungsbäume oder Klassifikatoren, die lediglich für den
dort lokalen Datenbestand Bedeutung haben.
2
So entstehen an den verteilten Orten mehrere Entscheidungsbäume oder Klassifikatoren.
Wünscht man einen globalen Klassifikator, so muss dieser aus den verteilt vorliegenden Klassifikatoren ein globales Modell generieren. Diese Aufgabe wird von so genannten meta-learningAlgorithmen übernommen. Die Definition folgt den Ausführungen von [PCS00].
19
20
Definition 2.10 Ein Meta-Lerner erzeugt, basierend auf verteilt vorliegenden Klassifikatoren, einen globalen Klassifikator.
2
Dabei können die verteilten Klassifikatoren mit unterschiedlichen Gewichtungen in die Modellgenerierung eingehen. So kann beispielsweise der Ansatz verfolgt werden, Klassifikatoren
aus Datenquellen mit wenigen oder bekanntermaßen qualitativ ungenauen Datensätzen bei der
globalen Modellgenerierung weniger zu berücksichtigen als solche, die unter Zuhilfenahme
großer oder bekanntermaßen qualitativ hochwertiger Basisdatensätze entstanden sind. Detailliertere Informationen zum Thema Meta-Lerner sind in [Pre05] nachzulesen.
Durch die Verteilung der Analysen kann auf die Zusammenführung der verteilten Datenbestände verzichtet werden, so dass finanzieller und zeitlicher Aufwand minimiert und die angesprochenen, datenschutzrechtlichen Gefährdungen umgangen werden. Somit eignet sich diese Vorgehensweise für verteilte Analysen auf großen Datenbeständen. Jedoch entsteht zusätzlicher Aufwand durch das Zusammenführen der verteilt erzeugten Klassifikatoren zu einem
globalen Klassifikator.
Mischformen von Verteilung und Zusammenführung
Weiterhin ist auch denkbar, eine Mischform der beiden vorgestellten Ansätze umzusetzen. Dazu muss zunächst eine Analyse der verteilten Datenbestände durchgeführt werden. Datenquellen, deren Schemata zueinander Ähnlichkeit aufweisen, sind potentielle Kandidaten für eine
Zusammenführung und Integration in eine gemeinsame Datenquelle. Auch Datenquellen, die
nur geringe Datenmengen vorhalten, können an einem Ort zusammengeführt und dort lokal
analysiert werden. Die Datenquellen, die große Datenmengen vorhalten, oder die, deren Datensätze sich schematisch stark voneinander unterscheiden, sind potentielle Kandidaten für eine
verteilte Analyse.
Nach Durchführung der Integration der Zusammenführungskandidaten und der Analyse auf
den zusammengeführten Daten sowie nach der verteilten Analyse der Quellen, die nicht zusammengeführt wurden, muss ein Meta-Lerner die durch die Analyseläufe entstandenen Basisklassifikatoren zusammenführen.
Ein erhoffter Nutzen einer derartigen Mischform ist, die Anzahl der Basisklassifikatoren zu
verringern und somit den Prozess des Generierens eines globalen Klassifikators zu vereinfachen. Dies gelingt nur, wenn die zu Grunde liegenden Datenquellen für eine solche Mischform
geeignet sind, d.h. wenn sich tatsächlich Datenquellen finden, die sich zusammenführen lassen. Letztlich kann erst nach Durchführung der Analyse tatsächlich festgestellt werden, ob das
Verfolgen der Durchführung einer Mischform der Analysen einen Vorteil erbracht hat, da sowohl für die Durchführung einer Voruntersuchung der Datenquellen als auch für die Integration der Zusammenführungskandidaten ein Aufwand betrieben werden muss, der den Aufwand,
der zur Durchführung einer verteilten Analyse auf allen Datenquellen betrieben werden muss,
nicht übersteigen darf. Interessant könnte dieser Ansatz für Szenarien sein, in denen periodisch
die selben Datenquellen analysiert werden sollen, wobei diese statische Schemata mit stetig
veränderten Attributbelegungen aufweisen.
2.3. Zusammenfassung
In diesem Kapitel wurden grundlegende Technologien vorgestellt, die im weiteren Verlauf dieser Arbeit Verwendung finden werden. So wurden in Abschnitt 2.1 die Grundlagen des Distributed Data Mining erläutert. Dazu zählen u.a. der Prozess des KDD, der in Abschnitt 2.1.1
20
2.3 Z USAMMENFASSUNG
21
vorgestellt wurde, und der KDD-Schritt des Data Mining, der in Abschnitt 2.1.2 erläutert wurde. Anschließend wurde in Abschnitt 2.1.3 eine Analyse des Data Mining, die Klassifikation, genauer erläutert. In diesem Zusammenhang wurde der Begriff des Entscheidungsbaumes
eingeführt und anhand eines Beispieles veranschaulicht. Es folgte eine Einführung in die Entscheidungsbauminduktion. Im Anschluss wurden in Abschnitt 2.1.4 die Komponenten einer
typischen Data Mining-Architektur vorgestellt. Darauf folgend wurde in Abschnitt 2.2 der Begriff des DDM erläutert. Nach einer Definition des Begriffes, die in Abschnitt 2.2.1 zusammen mit weiteren Begriffsklärungen durchgeführt wurde, wurden zwei Herangehensweisen
an DDM in der Anwendung von Entscheidungsbäumen anhand eines Beispieles näher vorgestellt. Eine Herangehensweise ist die in Abschnitt 2.2.2 erläuterte Task-Parallelisierung; bei
der anderen Herangehensweise handelt es sich um die in Abschnitt 2.2.3 beschriebene DatenParallelisierung. Im letzten Abschnitt dieses Kapitels, Abschnitt 2.2.4, wurde die Entscheidungsbauminduktion auf verteilte Anwendungsgebiete erweitert.
21
22
22
3. Architekturen
Das Thema dieser Arbeit umfasst die Ableitung eines Architektur-Konzeptes für ReKlaMeDDM-Analysen aus einem zu konzeptionierenden Ausführungsmodell. Daher werden im Abschnitt 3.1 zunächst einige Begriffsklärungen vorgenommen. Anschließend werden in Abschnitt 3.2 verschiedene komponentenbasierte Architektur-Ansätze und Architektur-Konzepte
vorgestellt und in Abschnitt 3.3 bewertet. In Abschnitt 3.4 wird dann aufgrund der Bewertungen ein Fazit gezogen und es werden verschiedene Implementierungen vorhandener komponentenbasierter Architekturen vorgestellt und bewertet. Eine Architektur wird ausgewählt und
anschließend in Abschnitt 3.5 ausführlich vorgestellt. Schließlich erfolgt in Abschnitt 3.6 eine
Zusammenfassung dieses Kapitels.
3.1. Was ist eine Software-Architektur?
In diesem Abschnitt wird zunächst der Begriff der Architektur definiert und erläutert. Anschließend erfolgt eine Klärung des Begriffes der Software-Komponente. Schließlich werden Vorteile
der Nutzung einer Software-Architektur aufgezeigt und der zugehörige Design-Prozess dargestellt.
Die Definition einer Architektur nach IEEE-Standard 1471-2000 [MEH01] lautet:
Definition 3.1 Eine Architektur ist die fundamentale Organisation eines Systemes, die
durch dessen Komponenten, deren Beziehungen zueinander und deren Umgebung festgelegt
wird.
2
Eine andere Definition mit stärkerem Bezug zum Gebiet der Softwareentwicklung ist [BCK03]
entnommen:
Definition 3.2 Die Software-Architektur eines Programmes oder eines Rechensystemes
ist die Struktur des Systems, die aus Software-Elementen, ihren sichtbaren Eigenschaften
und ihren Beziehungen untereinander bestehen.
2
Extern sichtbare Eigenschaften können in diesem Zusammenhang Annahmen sein, die Elemente über ein anderes Element machen können. Dazu zählen beispielsweise die von einem
Element angebotenen Dienste, deren Performance-Eigenschaften, die Fehlerbehandlung, die
Ressourcenausnutzung und weitere.
In beiden Definitionen werden die Begriffe Komponenten bzw. Elemente aufgeführt. Eine
Software-Komponente ist wie folgt definiert [Com04]:
Definition 3.3 Eine Software-Komponente ist ein Software-Objekt, welches darauf ausgelegt ist, mit anderen Komponenten zu interagieren oder eine Menge von spezifischen Funktionalitäten zu kapseln. Eine Komponente hat ein fest definiertes Interface und entspricht
einem vorgegebenen Verhalten gegenüber allen anderen Komponenten einer SoftwareArchitektur. Mehrere Komponenten können zusammengefügt werden, um neue Komponenten
zu implementieren.
2
23
24
K APITEL 3 - A RCHITEKTUREN
Komponenten sind in der Lage, mit anderen Komponenten zu kommunizieren, Daten auszutauschen oder Funktionalitäten anderer Komponenten zu nutzen. Eine komponentenbasierte Software-Architektur, im Folgenden nur als Architektur bezeichnet, umfasst die einzelnen
Komponenten, aus denen das System besteht, das Zusammenspiel dieser Komponenten untereinander sowie deren Schnittstellen zu Komponenten anderer Systeme.
In einer Architektur sind Kontroll- und Datenkommunikationsaufgaben umzusetzen. Erstere
dienen der Kontrolle anderer Komponenten. So kann eine Komponente einer Architektur einen
Dienst einer anderen Komponente aufrufen und ihn über Parameter konfigurieren, d.h. Einstellungen für den Ablauf des Dienstes vornehmen. Datenkommunikationsaufgaben dienen dem
Transport von Ein- und Ausgabedaten.
Abbildung 3.1.: Beispiel einer Architektur für eine Klassifikationsanalyse
Abbildung 3.1 zeigt das im Folgenden aufgezeigte Beispiel, anhand dessen die Kontroll- und
Datenkommunikationsaufgaben näher erläutert werden sollen. Die Komponente K, ein Klassifikationsalgorithmus, kann Eingabedaten über eine hier nicht näher spezifizierte Funktion
in Ausgabedaten wandeln. Um die Funktionalität zu ermöglichen, ist es die Aufgabe der
Architektur-Komponenten, die Eingabedaten für Komponente K zur Verfügung zu stellen und
die erzeugten Ausgabedaten an eine Visualisierungskomponente V weiterzureichen. Weiterhin
ist es die Aufgabe der Architektur, mögliche Konfigurationen, die über die Benutzungsschnittstellenkomponente B eingegeben wurden, an K weiterzuleiten. Datenflüsse sind in der Abbildung als gestrichelte Pfeile dargestellt, Kontrollflüsse als durchgezogene Pfeile.
Ein Anwender initiiert einen Analyselauf über die Nutzung der Benutzungsschnittstelle, die
Kontrolldaten an die Klassifikationskomponente sendet. Die Klassifikationskomponente sendet ihrerseits Kontrolldaten an die Datenhaltungskomponente DB, um an die Basisdaten für
einen Analyselauf zu gelangen. Daraufhin sendet die Datenhaltungskomponente die angeforderten Daten an die Klassifikationskomponente, die diese verarbeitet und die resultierenden
Ergebnisdaten an die Visualisierungskomponente weiterreicht.
3.1.1. Vorteile der Verwendung eines Architektur-Ansatzes
Soll ein Software-Projekt realisiert werden, muss eine Entscheidung bezüglich der Strukturierung der zu erstellenden Software getroffen werden. So kann die Software monolithisch, d.h.
in einem großen Block, entwickelt werden, oder es kann eine Implementierung unter Berücksichtigung eines Architektur-Konzeptes durchgeführt werden. Der Vorteil der Verwendung eines Architektur-Konzeptes anstelle eines monolithischen Programmes liegt in verschiedenen
Aspekten begründet, die in diesem Abschnitt erörtert werden. Dabei lehnt dieser Abschnitt an
die Ausführungen von [HR03] an.
Die Verwendung einer Architektur kann dabei helfen, ein System besser verstehen zu können,
indem durch die Architektur ein Vokabular für die Struktur und die Einschränkungen eines
24
3.1 WAS
IST EINE
S OFTWARE -A RCHITEKTUR ?
25
Systemes gegeben ist. Namen von Komponenten, ihre angebotenen Funktionalitäten, Schnittstellen sowie Kommunikationsverbindungen zählen zu diesem Vokabular. Dieses Vokabular
erleichtert auch die Planung größerer Projekte, an denen mehrere Entwickler beteiligt sind, da
es ihnen erleichtert wird, über einzelne Komponenten zu sprechen.
Weiter ermöglicht die Nutzung einer Architektur der Wiederverwendbarkeit der Komponenten.
Auch ganze Strukturen einer Architektur, die aus mehreren Komponenten bestehen, können
wiederverwendet werden. Die Wiederverwendbarkeit von Komponenten kann Vorteile in der
Entwicklung anderer Komponenten bieten, da Entwicklungsaufwand eingespart werden kann,
sofern sich eine einsetzbare Komponente findet, die die Entwicklung einer neuen Komponente
oder neuer Funktionalitäten für eine neue Komponente obsolet werden lässt.
Bei der Planung und Umsetzung einer Architektur können dank geplanter Schnittstellen und
Komponenten Teile einer Architektur oder ganze Subsysteme parallel von verschiedenen
Entwickler-Teams implementiert werden. Dies kann einerseits Zeit einsparen, andererseits
auch die Entwicklung sehr großer, komplexer Projekte ermöglichen, da die zu überblickenden
Bereiche in kleinere, von mehreren Entwicklern zu wartende Bereiche aufgeteilt werden.
Weiterhin wird die Analyse auf Systemebene erleichtert, da die Komponenten die Funktionalität in kleinen, strukturierten Einheiten kapseln und es somit erleichtert wird, einen Überblick
über ein System zu erhalten. Auch eine Aufwands- und Kosteneinschätzung für die Entwicklung eines Systemes wird durch die strukturierten Einheiten vereinfacht.
Schließlich kann die Erstellung eines evaluierbaren Meilenstein-Releases vereinfacht werden,
indem nicht alle Komponenten ausprogrammiert, sondern manche lediglich prototypisch implementiert werden. Somit ist es möglich, die bereits funktionsfähigen Komponenten zu testen,
ohne das Gesamtsystem in seiner vollen Funktionalität implementieren zu müssen.
Die zuvor aufgeführten Vorteile lassen sich durch Verwendung eines Architektur-Ansatzes
im Kontext dieser Arbeit nutzen. Gerade die Erleichterung der Erstellung eines evaluierbaren Meilenstein-Releases bietet im Rahmen dieser Arbeit Vorteile, da es aufgrund der Vielzahl
der zu implementierenden Komponenten und im Hinblick auf die zeitlichen Vorgaben nicht
möglich sein wird, alle Komponenten auszuprogrammieren. So werden einige Komponenten,
die nicht direkt zur Architektur des Szenarios gehören, nur prototypisch implementiert werden,
so dass der beschriebene Vorteil der Verwendung eines Architektur-Ansatzes hier zum Tragen
kommt.
Die Umsetzung eines Architektur-Ansatzes wird in einem Design-Prozess beschrieben, der im
folgenden Abschnitt stufenweise erläutert wird.
3.1.2. Der Design-Prozess
Der Design-Prozess befasst sich mit der Entwicklung einer Architektur für ein spezifisches Einsatzgebiet. Als Ausgangssituation liegen verschiedene Anforderungen an die Funktionalität des
zu entwerfenden Systemes vor. Auch Vorgaben bezüglich der Ein- und Ausgabeschnittstellen
bzw. der Einbettung des zu entwerfenden Systemes in eine vorgegebene Umwelt können vorliegen. Die Konzeption der in dieser Arbeit zu erstellenden Architektur lehnt sich an den im
Folgenden vorgestellten Prozess an.
In einem ersten Schritt wird auf einem sehr niedrigen Abstraktionsniveau ein statisches Strukturmodell entworfen, welches die Anforderungen an Funktionalität eines Systemes und dessen
Einbettung in andere Umgebungen abbildet und die Haupt-Systemkomponenten enthält.
Anschließend wird das System strukturiert, indem es in einzelne Subsysteme unterteilt wird.
Die Kommunikation zwischen diesen Subsytemkomponenten wird analysiert und identifiziert.
25
26
Dann werden die entstandenen Subsysteme in Module unterteilt. Ein Modul bezeichnet dabei ein durch Komposition mehrerer Komponenten entstehendes Subsystem mit spezifischer
Funktionalität und spezifischen Schnittstellen.
Darauf folgend wird der Entwurf eines dynamischen Prozess-Modelles durchgeführt. Das
Prozess-Modell beschreibt die Kontrollbeziehungen der verschiedenen Systeme und zeigt die
Kontroll-Datenflüsse auf.
Schließlich werden die Module auf vorhandene Ressourcen wie z.B. Prozessoren, Netzwerke und Datenspeicher abgebildet oder alternativ in Hardware implementiert. Es entsteht ein
Datenfluss-Modell, welches die Informationsflüsse im System abbildet.
Abschließend werden die Schnittstellen zu den Komponenten der Umgebung festgelegt. Das
Interface-Modell beschreibt die Modellierung dieser Schnittstellen.
Nicht-funktionale Anforderungen an eine Architektur umfassen verschiedene Aspekte, beispielsweise die Steigerung der Performance eines Systemes. Dazu wird versucht, die Kommunikation der Module untereinander zu minimieren. Auch Sicherheitsaspekte können bei
der Konzeption einer Architektur berücksichtigt werden. So können spezielle Strukturen erzeugt werden, die den Datenzugriff auf schützenswerte Daten kapseln. Schließlich besteht
die Möglichkeit, die Verfügbarkeit von Komponenten durch redundanten Einsatz dieser zu
erhöhen. Letztlich erleichtert das Aufteilen des Systemes in feingranulare Komponenten die
Wartbarkeit dieser.
Basierend auf diesem Design-Prozess können nun unterschiedliche Architektur-Ansätze implementiert werden, die wiederum mehrere Architektur-Konzepte umsetzen können. Der nächste
Abschnitt befasst sich mit diesen unterschiedlichen Architektur-Konzepten und -Ansätzen.
3.2. Überblick über verschiedene komponentenbasierte
Architekturen
In diesem Abschnitt erfolgt eine Untersuchung verschiedener Konzepte und Ansätze komponentenbasierter Architekturen, sowie der Grundlagen, auf denen sie basieren. Dabei wird
ausführlich auf die einzelnen Konzepte und Ansätze eingegangen.
Dem Einsatz einer komponentenbasierten Architektur liegt vor allem der Gedanke zugrunde,
bereits vorhandene Softwarekomponenten wiederverwenden zu können. Dabei sollen die Vorteile von Individual- und Standardsoftware vereint werden. Individual- und Standardsoftware
werden nach [Tes03] wie folgt definiert:
Definition 3.4 Mit dem Begriff der Individualsoftware bezeichnet man eine Software, die
direkt an den Anforderungen eines Kunden orientiert und für diesen implementiert ist. Standardsoftware bezeichnet eine Art Software, die eine allgemein verwendbare Lösung für ein
Problem anbietet.
2
Die Vereinigung der Vorteile von Individual- und Standardsoftware kommt zustande, indem
eine Auswahl standardisierter Komponenten nach kundenspezifischen Vorgaben erfolgt. Die
Standard-Komponenten werden anschließend bei Bedarf noch an die individuellen Vorgaben
des Kunden angepasst. Vorteile eines solchen Vorgehens ergeben sich durch eine verkürzte
Entwicklungszeit dank Rückgriffes auf vorhandene Komponenten. Weiterhin erlaubt die Wiederverwendung standardisierter Lösungen eine verbesserte Interoperabilität, höhere Qualität
und bessere Kontrolle von (finanziellen) Risiken [Tes03].
26
3.2 Ü BERBLICK ÜBER
VERSCHIEDENE KOMPONENTENBASIERTE A RCHITEKTUREN
Ein weiterer Vorteil des Einsatzes einer komponentenbasierten Architektur liegt in der Wiederverwendbarkeit der Komponenten. Sowohl an anderen Stellen des selben Projektes als auch in
anderen Projekten können durch die Wiederverwendung Entwicklungskosten eingespart werden. Durch eine zusätzliche Vermarktung der Komponenten ließen sich die Entwicklungskosten gegebenenfalls sogar kompensieren oder gar Gewinne erzielen.
Beispiele für Komponenten-Architekturen sind das Component Object Model (COM) [Mic04a]
und .NET [Mic04b], Enterprise Java Beans (EJB) [Sun04b] sowie das CORBA Component
Model (CCM) [OMG02]. Eine dieser Architekturen wird in Abschnitt 3.4 für die weitere Anwendung im Kontext dieser Arbeit ausgewählt und daran anschließend ausführlich untersucht.
Bezüglich der Umsetzung der Komponenten, die Bausteine innerhalb eines dieser Beispiele für Komponenten-Architekturen sind, existieren verschiedene Konzepte und Ansätze. Im
Folgenden werden zunächst grundlegende Konzepte vorgestellt, auf denen KomponentenArchitekturen basieren können. Anschließend werden verschiedene Ansätze zur Umsetzung der Komponenten aufgezeigt, die im Rahmen der Implementierung der ausgewählten
Komponenten-Architektur Anwendung finden können.
Der Umsetzung einzelner Komponenten einer Komponenten-Architektur können unterschiedliche Konzepte zu Grunde liegen. Drei Architektur-Konzepte können dabei unterschieden werden:
1. Konzept der Container-Architektur
2. Konzept der Client-Server-Architektur
3. Konzept der Multi-Layer-Architektur
In Abbildung 3.2 sind diese drei Konzepte als Ellipsen dargestellt. Jeder der im Folgenden
vorgestellten Architektur-Ansätze basiert auf mindestens einem der drei Konzepte und wird
in Abbildung 3.2 durch ein Rechteck visualisiert. Die vorgestellten Ansätze können optional auf verschiedenen Konzepten basieren, wobei die Konzepte durchaus kombiniert werden
können. Beispielsweise kann eine agentenbasierte Architektur einige oder alle Eigenschaften
einer Container-, Client-Server- und einer Multi-Layer-Architektur miteinander vereinen. Diese Konzepte werden im folgenden Abschnitt genauer untersucht. Daran anschließend werden
die Architektur-Ansätze erläutert.
Abbildung 3.2.: Überblick über verschiedene komponentenbasierte Architektur-Ansätze und
deren Beziehungen untereinander
27
27
28
3.2.1. Architektur-Konzepte
Ein grundlegendes Konzept, auf dem verschiedene Architektur-Ansätze basieren können, ist
das der Container-Architektur. Dieses Konzept zeichnet sich dadurch aus, dass die Architektur
eine Art Behälter“ (Container) zur Ausführung von Software-Komponenten zur Verfügung
”
stellt, der als Laufzeitumgebung fungiert und eine Menge von speziellen Diensten anbietet.
Diese Dienste können von einer Software-Komponente genutzt werden, welche innerhalb des
Containers gehalten wird [HSS+ 03].
Ein Beispiel für das Container-Konzept in Verbindung mit einer Komponenten-Architektur
ist das J2EE-Konzept [Sun04a], das einen EJB-Container im Rahmen der EJB-Architektur
[Sun04b] bereitstellt. Beispielhafte Dienste, die dieser Container anbietet, umfassen u.a. Dienste zur Schaffung von Persistenz oder Referenzierbarkeit von Komponenten im Container,
Dienste zur Organisation der Kommunikation einzelner Komponenten untereinander oder
Dienste, die den Komponenten die Nutzung der Dienste anderer Komponenten ermöglicht.
Nähere Informationen zu J2EE und EJB finden sich unter [Sun04a], [DP02] sowie in Kapitel
3.5.
Ein weiteres, grundlegendes Konzept, welches Anwendung in verschiedenen ArchitekturAnsätzen finden kann, ist das Client-Server-Konzept. Das Client-Server-Konzept basiert auf
einem verteilten Modell, in welchem festgelegt wird, wie eine Menge von Daten und deren
Verarbeitung auf eine Menge verteilter Komponenten aufgeteilt werden kann [HR03]. Es existiert eine Menge von Servern, die spezifische Dienste für andere Komponenten anbieten. Genutzt werden diese Dienste von den Clients, die über ein Netzwerk mit den Servern verbunden
sind.
Die Vorteile des Einsatzes des Client-Server-Konzeptes liegen in der einfachen Realisierbarkeit
von Verteiltheit. Weiter können vorhandene Systeme, die an eine Netzwerk-Struktur angebunden sind, unter Umständen effektiver ausgelastet werden, da die Möglichkeit besteht, in eventuell auftretenden Idle-Phasen die Daten anderer Clients zu bearbeiten. Schließlich ist es einfach
möglich, neue Server mit neuen Diensten in ein bestehendes System einzubinden [HR03].
Der Einsatz des Client-Server-Konzeptes kann auch Nachteile mit sich bringen. So existiert
kein gemeinsames Datenmodell der Komponenten, d.h. die Komponenten nutzen unterschiedliche Daten-Organisationsstrukturen. Auch der Austausch von Daten kann sich als ineffizient
darstellen. Jeder Server muss eine eigene Verwaltungskomponente aufweisen, was u.U. Redundanzen zur Folge haben kann. Zuletzt existiert kein zentrales Register, in dem Namen oder
Dienste vorgehalten werden, so dass es in der Regel nicht trivial ist, einen Überblick über
Server und Dienste zu gewinnen.
Das Multi-Layer-Konzept kann ebenfalls als Grundlage der im Folgenden vorgestellten
Architektur-Ansätze dienen. Dieses Konzept zeichnet sich dadurch aus, dass unterschiedliche
Abstraktionsebenen einer Komponente in verschiedenen, hierarchisch geordneten Schichten
organisiert werden.
Das klassische Beispiel für eine Multi-Layer-Architektur ist das OSI-Referenzmodell [KB94].
Abbildung 3.3 zeigt die einzelnen Schichten des OSI-Referenzmodelles und ihre hierarchische Anordnung. Jede Schicht bietet eine Menge von Schnittstellen, und die Elemente einer
Schicht sind auf unterschiedlichen Abstraktionsebenen ausgeführt. Der Grad der Abstraktion
verringert sich von der Stufe der Anwendungsschicht bis zur Stufe der Bitübertragung. Nähere
Informationen zum OSI-Referenzmodell sind [KB94] zu entnehmen.
Mit Kenntnis dieser drei Architektur-Konzepte können nun im folgenden Abschnitt drei
Architektur-Ansätze vorgestellt werden. Sie beruhen auf den zuvor beschriebenen Konzepten.
28
29
Abbildung 3.3.: Das ISO-OSI-Referenzmodell als Beispiel für eine Multi-Layer-Architektur
(nach [KB94])
3.2.2. Architektur-Ansätze
In diesem Abschnitt werden drei unterschiedliche Architektur-Ansätze vorgestellt und näher
untersucht. Dabei werden die Charakteristika der unterschiedlichen Ansätze aufgezeigt und
gegenübergestellt.
Agentenbasierter Ansatz
Zur Erläuterung eines agentenbasierten Architektur-Ansatzes bedarf es zunächst der Klärung
des Begriffes Agent. Die folgende Definition entstammt den Ausführungen von [Fer01], an die
auch der gesamte Abschnitt über den agentenbasierten Ansatz angelehnt ist.
Definition 3.5 Ein Agent ist eine physische oder virtuelle Entität,
• die selbständig in einer Umwelt agieren kann
• die direkt mit anderen Agenten kommunizieren kann
• die durch eine Menge von Absichten angetrieben wird (in Form von individuellen Zielen, Befriedigungs- und Überlebensfunktionen, die sie zu optimieren versucht)
• die eigene Ressourcen besitzt
• die fähig ist, ihre Umwelt wahrzunehmen (jedoch nur in einem bestimmten Ausmaß)
• die nur eine partielle Repräsentation ihrer Umwelt besitzt
• die bestimmte Fähigkeiten besitzt und Dienste offerieren kann
• die sich gegebenenfalls selbst reproduzieren kann
• deren Verhalten darauf ausgerichtet ist, ihre Ziele unter Berücksichtigung der ihr zur
Verfügung stehenden Ressourcen und Fähigkeiten zu befriedigen und die dabei auf ihre
Wahrnehmung, ihre internen Modelle und ihre Kommunikation mit anderen Agenten
(oder den Menschen) angewiesen ist und
• die die Eigenschaft der Mobilität aufweist.
2
29
30
Als physische Entität sei in diesem Zusammenhang ein Objekt bezeichnet, welches in der realen Welt agiert. Eine virtuelle Entität bezeichnet eine Software-Komponente oder ein Rechenmodul.
Der Begriff der Mobilität ist eine der Kerneigenschaften eines Agenten und sei wie folgt definiert:
Definition 3.6 Mobilität bezeichnet die Fähigkeit eines Agenten, innerhalb der Umwelt
eines Multiagentensystemes mit verschiedenen Agenten an verschiedenen Positionen zu interagieren. Dies beinhaltet die Fähigkeit, von einer Plattform auf eine andere zu migrieren.
2
Ein weiterer Begriff im Zusammenhang mit Agenten ist der Begriff der Intelligenz, der definiert
sei durch:
Definition 3.7 Der Begriff der Intelligenz eines Agenten steht für dessen Eigenschaften der Selbständigkeit, Wahrnehmung der Umwelt sowie der Proaktivität, die aus der eigenständigen Erstellung und dem Streben nach Erfüllung selbst gesteckter Ziele resultiert.
2
Zur Klärung der Begriffe Multiagentensystem und Umwelt sei folgende Definition angeführt:
Definition 3.8 Ein Multiagentensystem (MAS) bezeichnet ein System, das aus folgenden
Elementen besteht:
• Eine Umwelt U . U ist ein Raum, der im Allgemeinen ein Volumen hat.
• Eine Menge von Objekten O. Diese sind situiert, das bedeutet, dass zu einem beliebigen
Zeitpunkt jedem Objekt eine Position in U zugewiesen werden kann. Objekte können
von Agenten wahrgenommen, erzeugt, modifiziert und gelöscht werden.
• Eine Menge von Agenten A. Diese repräsentieren die aktiven Objekte (A ⊆ O) des
Systems.
• Eine Menge von Beziehungen, B, die Objekte miteinander verbinden.
• Eine Menge von Operationen Op, damit Agenten Objekte empfangen, erzeugen, konsumieren, verändern und löschen können.
• Operatoren mit der Aufgabe, die Anwendung dieser Operationen und die Reaktion der
Umwelt auf die entsprechenden Veränderungsversuche darzustellen.
2
Auf Grundlage dieser Definitionen kann nun die eigentliche Definition eines Software-Agenten
erfolgen:
Definition 3.9 Ein Software-Agent (SWA) ist eine Software-Komponente, die in einem
Netz von anderen Komponenten existiert, mit diesen kommunizieren kann und durch eine
Menge an eigenen Zielen angetrieben wird. Ein SWA besitzt eigene Ressourcen und bietet
anderen Komponenten eigene Dienste an. Er zeigt zielorientiertes Verhalten, welches sich an
seinen verfügbaren Ressourcen und Fähigkeiten orientiert. Ein SWA weist die Eigenschaft
der Mobilität auf, d.h. er kann innerhalb eines MAS mit verschiedenen SWA an verschiedenen Positionen interagieren.
2
30
Durch die Mobilitäts-Eigenschaft ergeben sich neue Möglichkeiten in Hinblick auf verteilte
Architekturen. So kann ein Agent zu verschiedenen Datenbeständen migrieren und vor Ort
beispielsweise Analysen abarbeiten, was bei großen Datenmengen von Vorteil ist, da in einem
solchen Fall die Daten nicht kommuniziert werden müssen. Allerdings existieren auch Nachteile: so muss ein erhöhter Management-Aufwand bedacht werden, der für die Verwaltung der
Agenten, deren Lokalisierung und Steuerung aufgebracht werden muss. Auch Datenschutzbestimmungen und Sicherheitsaspekte können den Einsatz von Agenten verbieten, da Daten,
die unter Umständen vertrauliche Informationen beinhalten und von einem Agenten analysiert
werden, durch dessen Kommunikationsmöglichkeiten mit anderen Agenten diese gegebenenfalls preisgegeben werden könnten.
Der agentenbasierte Architektur-Ansatz verfolgt nun die Intention, die Komponenten, die in
einer Architektur zusammengefasst werden sollen, als Software-Agenten umzusetzen. Dabei
können die Vorteile von Software-Agenten, wie z.B. die Mobilität, genutzt werden, um beispielsweise in verteilten Szenarien die Bearbeitung von Aufgaben zu erleichtern, indem Datenflüsse minimiert werden.
Mediator-Wrapper-Ansatz
Der Ansatz der Mediator-Wrapper-Architektur vereinigt die Software-Entwicklungsmuster
Mediator und Wrapper, die im Folgenden zunächst definiert werden. Die Definitionen orientieren sich an den Ausführungen von [GHJV95].
Definition 3.10 Ein Mediator ist für die Koordination der Interaktionen einer Gruppe
von Objekten verantwortlich. Er dient als Vermittler, der die Objekte einer Gruppe davon
abhält, explizit aufeinander zu verweisen. Die Objekte sehen nur den Mediator und verweisen über ihn auf andere Objekte der Gruppe, wodurch die Anzahl der Verbindungen reduziert
wird.
2
Ein Mediator lässt sich sinnvoll anwenden, wenn eine Menge von Objekten in wohldefinierten, aber komplexen Protokollen miteinander kommunizieren, da in diesem Fall ohne Anwendung eines Mediators unstrukturierte und schwer verständliche Abhängigkeiten zwischen den
Komponenten entstehen können. Auch die Wiederverwendbarkeit einer Komponente, die nicht
über einen Mediator mit anderen Komponenten verbunden ist, kann komplexer sein, da die
Kommunikationsverbindungen unter Umständen spezifischer Art sind und somit bei Wiederverwendung in einem anderen Kontext reimplementiert werden müssten [GHJV95]. Die Verwendung von vorgegebenen Standards bezüglich der Kommunikationsverbindungen entspricht
vom Prinzip her dem Konzept eines Mediators, da hier anstelle einer Mediator-Komponente
bereits auf konzeptioneller Ebene eine Art Mediation durchgeführt wird.
Definition 3.11 Ein Wrapper ist ein Objekt, welches eine andere Komponente umhüllt,
um diese um zusätzliche Funktionalität zu erweitern. Die Schnittstelle zum Wrapper-Objekt
ist identisch zur Schnittstelle der umhüllten Komponente, um Transparenz gegenüber potentiellen Clients zu gewährleisten. Der Wrapper leitet Anforderungen an die Komponente weiter,
kann dabei vor oder nach Weiterleitung zusätzliche Aktionen ausführen. Durch die Transparenz können mehrere Wrapper übereinander gelegt werden und somit uneingeschränkte
Erweiterungsmöglichkeiten bieten .
2
Die Anwendung von Wrappern ist zu empfehlen, um Verantwortlichkeiten an individuelle Objekte transparent und dynamisch weiterzugeben, ohne andere Objekte dabei zu beeinflussen.
Ebenso wird die Aufhebung von Verantwortlichkeiten für individuelle Objekte ermöglicht.
31
31
32
Schließlich sind Wrapper sinnvoll einzusetzen, wenn die Erweiterung von Objekten um Unterklassen nicht praktikabel ist [GHJV95].
Bezüglich einer Architektur lassen sich die beiden Konzepte Mediator und Wrapper miteinander verbinden, indem um die Dienste eines Servers ein Wrapper konstruiert wird, der den
Server um die Eigenschaften eines Mediators erweitert. So können beispielsweise Mediatoren
als Wrapper um einen Bestand von Datenquellen mit unterschiedlichen Schnittstellen konstruiert werden, um einen einheitlichen Zugriff auf die Datenquellen für Clients zu ermöglichen.
Web-Service-basierter Ansatz
Web-Services stellen eine aktuelle Entwicklung im Bereich des Software Engineering dar. Die
Definition von Web-Services lautet nach [W3C04]:
Definition 3.12 Ein Web-Service ist ein Software-System, welches zur Unterstützung von
interoperabler Interaktion von Maschine zu Maschine über ein Netzwerk konzeptioniert ist.
Ein Web-Service hat eine Schnittstelle, die in einem von Maschinen verarbeitbaren Format,
in der Sprache WSDL, umgesetzt ist. Andere Systeme können mittels SOAP-Nachrichten mit
einem Web Service in einer durch seine Beschreibung vorgegebenen Art interagieren.
2
In der Definition treten zudem die Begriffe WSDL und SOAP auf, die nach [W3C04] bzw.
[W3C03] wie folgt definiert werden:
Definition 3.13 WSDL steht für den Begriff Web Service Description Language und bezeichnet eine Sprache zur Beschreibung der Dienste, die ein Web-Service anbietet. Sie ist
von Maschinen verarbeitbar und definiert Nachrichtenformat, Datentypen, Transportprotokolle und Transport-Serialisierungsformate für die Kommunikation zwischen einem Client
und einem dienstanbietenden Web-Service. WSDL ist ein XML-Dialekt.
2
Definition 3.14 SOAP steht für den Begriff Simple Object Access Protocol und bezeichnet ein Protokoll zum Austausch von strukturierten Informationen in einer dezentralisierten, verteilten Umgebung. SOAP nutzt XML-Technologie zur Definition eines erweiterbaren
Nachrichten-Frameworks, welches Nachrichten-Konstrukte bereitstellt, die über eine Reihe
verschiedener Protokolle ausgetauscht werden können. Das Framework ist auf Unabhängigkeit von speziellen Programmierungsmodellen oder anderen implementationsspezifischen
Semantiken ausgerichtet.
2
Die Web Service Architecture des W3C [W3C04], eine Referenz-Architektur für Web-Services,
besteht aus drei Komponenten, die jeweils miteinander interagieren können. Es existieren Anbieter, die Dienste zur Verfügung stellen und Beschreibungen dieser in der Service Registry
hinterlegen, und Nutzer, die die Service Registry durchsuchen und gefundene Dienste in ihre
Anwendungen einbinden.
Ein Vorteil des Einsatzes von Web-Services liegt unter anderem darin, dass verschiedene Komponenten unabhängig von der Sprache, in der sie implementiert wurden, miteinander interagieren können. Zudem können die Komponenten über ein Netzwerk verteilt auf unterschiedlichen
Maschinen vorliegen, sie können aber auch innerhalb eines Systemkontextes gehalten werden.
Nutzer der Dienste von Web-Services können Web-Services, die Dienste anbieten, über die
Service Registry entdecken und zur Laufzeit auf die Dienste zugreifen. Die Wiederverwendbarkeit der Web-Service-Komponenten steht bei diesem Ansatz im Vordergrund. Die strikte
32
3.3 B EWERTUNGEN DER
VORGESTELLTEN
A RCHITEKTUR -KONZEPTE UND -A NS ÄTZE IM KONTEXT
DIESER
A RBEIT
Einbindung der Web-Services in ihren Ausführungskontext verhindert jedoch auch, dass WebServices spezifisch an eigene Bedürfnisse angepasst werden können. Sie können lediglich in
dem für sie vorgesehenen Kontext tätig sein. Somit ist eine Rekonfiguration der Web-Services
für den Einsatz in einem anderen Kontext, beispielsweise mit leicht abgeänderter Funktionalität, nicht ohne weiteres möglich [Tes03].
3.3. Bewertungen der vorgestellten Architektur-Konzepte
und -Ansätze im Kontext dieser Arbeit
In diesem Abschnitt erfolgt eine Bewertung der vorgestellten Architektur-Konzepte und
Architektur-Ansätze im Kontext der Verwendung für diese Arbeit. Ein in diesem Zusammenhang interessantes Anwendungsgebiet stellt die Bearbeitung verteilter Aufgaben dar. In dem
in dieser Arbeit behandelten Szenario soll die Klassifikation von verteilten Datenbeständen
jeweils an dem Ort stattfinden, an dem die Datenquelle lokalisiert ist. Die Komponenten der
zu konzeptionierenden Architektur müssen somit die Anbindung unterschiedlicher, verteilter
Datenquellen ermöglichen. Somit ist es erforderlich, dass die zu verwendenden ArchitekturAnsätze und Architektur-Konzepte verteilte Szenarien umfassend unterstützen. Dieser Aspekt
wird ausschlaggebend bei der Entscheidung für den Einsatz einer Architektur berücksichtigt.
Daher werden in diesem Abschnitt die vorgestellten Architektur-Konzepte und ArchitekturAnsätze neben anderen Eigenschaften auch speziell unter diesem Aspekt genauer untersucht.
3.3.1. Agentenbasierte Architekturen
Bezüglich der umsetzbaren Konzepte in einer agentenbasierten Architektur lassen sich viele
Ansatzpunkte aufzeigen. So kann die Umwelt des MAS als eine Art Container umgesetzt werden, die den Rahmen für den Lebenszyklus der darin befindlichen SWA bietet. Das MAS kann
Dienste z.B. zur Lokalisierung oder Instantiierung von Agenten zur Verfügung stellen. Somit könnten die Eigenschaften einer Container-Architektur umgesetzt werden. Innerhalb des
MAS können Agenten wiederum Eigenschaften des Konzeptes der Client-Server-Architektur
aufweisen, wobei dies durch die Definition eines SWA bereits in Teilen implizit vorgegeben
ist. SWA können als Client fungieren, indem sie Dienste anderer SWA nutzen, oder aber als
Server, indem sie Dienste für andere SWA zur Verfügung stellen. Auch das Konzept der MultiLayer-Architektur kann bei der Implementierung eines SWA einfließen. Wie bereits definiert,
ist ein SWA eine Softwarekomponente, die unter Berücksichtigung des Multi-Layer-Konzeptes
in mehreren Schichten, die jeweils eigene Abstraktionsebenen darstellen, umgesetzt werden
kann.
Die Mobilität eines Agenten bietet in verteilten Szenarien Vorteile bezüglich der Einsparung
von Kosten im Bereich der Datenkommunikation. Diese Eigenschaft ist in verteilten Szenarien
als positive Eigenschaft zu verzeichnen, so dass agentenbasierte Architektur-Ansätze für die
Verwendung im Kontext dieser Arbeit als geeignet erscheinen.
Abgebildet auf das Szenario dieser Arbeit kann ein SWA zu den unterschiedlichen, verteilten Datenbeständen migrieren und dort lokal Entscheidungsbäume induzieren. Anschließend
kann der SWA die entstandenen Basisklassifikatoren an einen anderen SWA kommunizieren,
der die Funktionalität eines Meta-Lerners implementiert und einen globalen Klassifikator erzeugt. Daraufhin kann der meta-lernende SWA die Ergebnisse an einen visualisierenden SWA
kommunizieren, der die Visualisierung umsetzt. Es können multiple Instanzen von Agenten
eingesetzt werden, um parallel auf unterschiedlichen Datenquellen mobil und verteilt Entscheidungsbäume zu induzieren. Dies kann zusätzlich einen Geschwindigkeitsvorteil erbringen.
33
33
34
Die Intelligenz eines Agenten ist im Kontext dieser Arbeit jedoch nicht von zusätzlichem
Nutzen. Die Art der Schnittstellen zu den einzelnen Datenquellen ist fest vorgegeben. Auch
die Induktion der Klassifikatoren kann einem statischen Schema folgen, so dass die Entwicklung der Intelligenz vom Agenten auf die Konzeption der Komponenten zur Anbindung
der Datenquellen und zur Umsetzung der Algorithmen zur Induzierung der Klassifikatoren
vorverlagert werden kann. Ein solches Vorgehen vermeidet den Bedarf der Umsetzung der
Intelligenz-Eigenschaften, die einen hohen Implementierungsaufwand erfordern und in komplexeren Ausführungsumgebungen resultieren. Unter dem Aspekt der Minimierung von Kosten
und Komplexität der Entwicklung eines Architektur-Ansatzes kann daher auf die Eigenschaft
der Intelligenz der Komponenten verzichtet werden. Zudem resultiert aus der Verringerung der
Komplexität eine leichtere Wartbarkeit und bessere Übersichtlichkeit des Projektes.
Zusammengefasst eignet sich der Ansatz einer agentenbasierten Architektur nur im metaphorischen Sinne, d.h. ausschließlich spezifische Einzelaspekte des agentenbasierten Ansatzes sind
für die Konzeption der Architektur im Kontext dieser Arbeit von Interesse. Der Aspekt der Mobilität kann als hilfreich und sinnvoll für die zu konzipierende Architektur vermerkt werden.
Auch die Kommunikationsfähigkeiten, die aus der Vernetzung der Agenten resultieren, können
in eingeschränkter Form von Vorteil für die Koordination der verschiedenen Komponenten
sein. Die Möglichkeit, dass Agenten spezifische Dienste anbieten, die von anderen Agenten
genutzt werden können, lässt sich auf Eigenschaften von generischen Software-Komponenten
abbilden und stellt somit keinen spezifischen Vorteil dieses Architektur-Ansatzes dar. Diese
Eigenschaft ist jedoch essentiell für die Konzeption einer Architektur im Kontext dieser Arbeit. Durch die Eigenschaften der Proaktivität und Intelligenz von Agenten, die keinen Vorteil,
sondern ausschließlich Nachteile mit sich bringen, wird im Kontext dieser Arbeit jedoch von
der Implementierung einer agentenbasierten Architektur in ihrer ursprünglichen Definition Abstand genommen.
3.3.2. Mediator-Wrapper-Architekturen
Mediator-Wrapper-Architekturen können, wie bereits in 3.2.2 beschrieben, dann sinnvoll eingesetzt werden, wenn die Elemente einer Menge von Komponenten in wohldefinierten, aber
komplexen Protokollen miteinander kommunizieren. Ein verteiltes Szenario erfordert Komponenten, die miteinander kommunizieren können, um Daten oder Kontrollanweisungen auszutauschen. Der Einsatz eines Mediators hilft dabei, diese Kommunikationsverbindungen zu
strukturieren und übersichtlich zu gestalten. Im Kontext dieser Arbeit werden Kommunikationsverbindungen zwischen den Klassifikations-Komponenten, den steuernden Komponenten
sowie der Meta-Lern-Komponente unumgänglich umzusetzen sein. Da verschiedene Klassifikationskomponenten auf unterschiedlichen Datenquellen arbeiten könnten, empfiehlt sich der
Einsatz von Mediatoren aus den zuvor genannten Gründen.
Die Implementierung der Mediatoren kann am Konzept des Wrappers orientiert werden, um eine Transparenz der Schnittstellen der Komponenten nach außen zu garantieren. Zudem können
bei Einsatz des Wrapper-Konzeptes individuelle Eigenschaften für individuelle Komponenten
festgelegt werden, ohne dass andere Komponenten beeinflusst werden.
Das Konzept der Client-Server-Architektur fließt dabei mit in die Architektur ein, indem die
per Mediator verbundenen Komponenten die Rolle von Client und Server übernehmen. Das
Konzept der Multi-Layer-Architektur kann bei der Einbettung des Wrapper-Konzeptes einfließen, indem dieser als zusätzliche Abstraktionsebene in einer äußeren Schicht die jeweilige
Komponente umhüllt.
Insgesamt eignet sich der Ansatz der Mediator-Wrapper-Architektur für die Verwendung im
34
3.4 FAZIT DER B EWERTUNGEN
35
Kontext dieser Arbeit bei der Konzeption der Architektur und wird diesbezüglich Berücksichtigung finden.
3.3.3. Web-Service-Architekturen
Der größte Vorteil, den Web-Services bieten, die Auswahl und Nutzung bereits vorhandener
Komponenten, ist im Kontext dieser Arbeit schwer zu nutzen. Es werden sich keine bereits fertig implementierten Web-Services finden lassen, die die sehr spezifischen Anforderungen, die
in der Architektur dieser Arbeit zu erfüllen sind, umsetzen können. Zu diesen Anforderungen
zählt beispielsweise unter anderem die Anbindung unterschiedlicher Datenquellen an mögliche
Klassifikationskomponenten. Aufgrund der fehlenden Möglichkeit, Web-Services nachträglich
zu rekonfigurieren, also auf die spezifischen Bedürfnisse zuschneiden zu können, entfällt dieser
Vorteil des Web-Service-Konzeptes also.
Da der Aufwand sehr hoch ist, die Eigenschaften zu implementieren, die die Wiederverwendbarkeit selbst erstellter Komponenten ermöglichen, würden die Kosten für die Konzeption der
Architektur erheblich steigen, ohne einen Mehrwert zu bringen. Daher wird auf die Verwendung des Web-Service-Ansatzes im Rahmen dieser Arbeit verzichtet.
Der Ansatz der Service-Registry ist hingegen im Kontext dieser Arbeit von Interesse, um eine
Art Verzeichnis über die Dienste, die von unterschiedlichen Komponenten angeboten werden,
zu erstellen. Anhand eines solchen Verzeichnisses ist es einfacher möglich, Dienste zu lokalisieren und zu verwenden.
3.4. Fazit der Bewertungen
In diesem Abschnitt wird eine Zusammenfassung der im vorigen Abschnitt vorgestellten
Konzepte und Ansätze gegeben. Anschließend werden verschiedene Implementierungen von
Komponenten-Architekturen auf Grundlage der Bewertungen untersucht und es wird die Auswahl einer speziellen Komponenten-Architektur getroffen.
Unter Berücksichtigung der Anforderungen, die der Konzeption einer Architektur für den
Kontext dieser Arbeit zugrunde liegen, lässt sich keiner der untersuchten Architektur-Ansätze
ohne Kompromisse einsetzen. Daher wird bei der weiteren Konzeption versucht, die positiven Komponenten-Eigenschaften der untersuchten Architektur-Ansätze und -Konzepte sinnvoll miteinander zu verbinden und in die zu entwerfende Architektur einfließen zu lassen.
Aus dem agentenbasierten Ansatz könnte dabei die Eigenschaft der Mobilität übernommen
werden. Die Eigenschaft der Mobilität würde eine optimierte Datenkommunikation der verteilten Komponenten untereinander ermöglichen. Auch die Option einer Vernetzung der Komponenten ist eine Eigenschaft, die in der zu konzipierenden Architektur erwünscht ist.
Der Mediator-Wrapper-Ansatz bietet die Vorteile einer strukturierten Kommunikation durch
Verwendung eines Mediators. Ein Wrapper ermöglicht die individuelle Erweiterung einzelner
Komponenten bei transparentem Erscheinungsbild. Daher könnten Mediatoren und Wrapper
Berücksichtigung bei der Konzeption der Architektur finden.
Der Web-Service-Ansatz bietet als einzige, verwertbare Eigenschaft die Service Registry, über
die sich Dienste von Komponenten lokalisieren lassen. Die Implementierung dieser Eigenschaft könnte daher bei der Konzeption der Architektur Berücksichtigung finden.
Um den Komponenten verschiedene Basisfunktionen zur Hand zu geben, ist das Konzept des
Containers von Interesse. So könnte beispielsweise die Kommunikation der Komponenten über
35
36
Container-Funktionen abgewickelt werden. Hier ließen sich verschiedene Anwendungen im
Laufe der Konzeption der Architektur finden.
Das Client-Server-Konzept wird aufgrund der bereits aufgeführten KomponentenEigenschaften Anwendung finden. Über die Verwendung des Multi-Layer-Konzeptes kann
beim Entwurf der einzelnen Komponenten entschieden werden. Einige Komponenten können
von einem Mehrschichtenaufbau profitieren, bei anderen wird dieses Konzept keinen Vorteil
erbringen.
Die wichtigste Eigenschaft, die der Auswahl für den Einsatz einer spezifischen Architektur zugrunde liegt, ist die Unterstützung von Verteiltheit der Komponenten. Somit muss diese Eigenschaft von der auszuwählenden Architektur umfangreich unterstützt werden. Eine zusätzliche
Vorgabe ist die Implementierung der Architektur und ihrer Komponenten in der Sprache Java.
Auf Basis dieser Eigenschaften können nun vorhandene Architektur-Implementierungen auf
ihre Eignung für den Einsatz im Kontext dieser Arbeit hin untersucht werden.
COM und .NET als verbreitete Architektur-Implementierungen scheiden somit bereits aufgrund der Vorgabe der Implementierungssprache aus, da sie in erster Linie C/C++ bzw. C#
unterstützen bzw. für den Einsatz von Java (derzeit noch) nicht geeignet erscheinen.
Im Rahmen des Habilitationsprojektes von Dr. Frank Köster wurde eine agentenbasierte Architektur (siehe [Bär03], [Meh03] und [Rob04]) entworfen, die die bereits beschriebenen Vorteile
einer agentenbasierten Architektur aufweist. Ein weiterer Vorteil des Einsatzes dieser Architektur bestünde in der direkten Greifbarkeit der Autoren, um bei Nachfragen Hilfestellung geben
zu können, da sie im Umfeld der Einrichtung, an der diese Arbeit bearbeitet wird, tätig sind. Die
Implementierung dieser Architektur bietet jedoch zu viele Eigenschaften, die im Rahmen des
Einsatzes in dieser Arbeit nicht von zusätzlichem Nutzen sind bzw. deren Implementierungsoder Adaptationsaufwand nicht im Verhältnis zum gewonnenen Nutzen steht und daher nicht
vertretbar erscheint. Zu diesen Eigenschaften zählt beispielsweise eine Konfigurierbarkeit von
Agenten zur Laufzeit, die im Kontext der Architektur, die in dieser Arbeit konzeptioniert werden soll, keinen Mehrwert bietet. Daher wird vom Einsatz dieser Implementierung einer agentenbasierten Architektur ebenfalls abgesehen.
Das J2EE-Konzept [Sun04a], und im Speziellen die EJB-Architektur [Sun04b] erscheinen
demgegenüber geeignet, um die Anforderungen an eine Architektur im Kontext dieser Arbeit
zu erfüllen. Sie bieten eine umfangreiche Unterstützung bezüglich der Verteiltheit von Komponenten und weisen zudem viele der im Vorfeld als wünschenswert identifizierten Eigenschaften auf. Zusätzlich sehen [DP02] die EJB-Architektur als die Standard-KomponentenArchitektur für die Erstellung verteilter Geschäftsanwendungen in der Programmiersprache Java an. Schließlich lassen sich, je nach Bedarf, die als wünschenswert identifizierten
Architektur-Eigenschaften flexibel abbilden. Daher fällt die Wahl der im Kontext dieser Arbeit
zu implementierenden Architektur auf die im J2EE-Konzept eingebettete EJB-Architektur.
3.5. J2EE und EJB
Dieser Abschnitt gibt eine Einführung in den Aufbau, die Bestandteile und die Eigenschaften
der EJB-Architektur, die für die Implementierung der Architektur im Kontext dieser Arbeit
ausgewählt wurde. Die einzelnen Komponenten und Konzepte, die dieser Architektur zugrunde
liegen, werden ausführlich vorgestellt. Grundlage dieses Abschnittes bilden die Ausführungen
von [DP02].
Zunächst werden in Abschnitt 3.5.1 einige Begriffe geklärt, deren Kenntnis zum Verständnis
der EJB-Architektur vorausgesetzt wird. Dann erfolgt in Abschnitt 3.5.2 die Einordnung der
36
3.5 J2EE UND EJB
37
EJB-Architektur in den Kontext des J2EE-Konzeptes. Anschließend wird die EJB-Architektur
in Abschnitt 3.5.3 ausführlich betrachtet und ihre Komponenten werden einzeln vorgestellt.
Schließlich werden in Abschnitt 3.5.4 die zur Implementierung und Nutzung einer Bean notwendigen Schritte vorgestellt.
3.5.1. Grundlegende Begriffsklärungen
Im Zusammenhang mit der Programmiersprache Java existieren die Begriffe JavaBean, Enterprise JavaBeans und Enterprise-Bean, die voneinander zu unterscheiden sind. Oftmals wird der
Begriff der JavaBean mit dem der Enterprise-Bean verwechselt, so dass eine genaue Abgrenzung der Begriffe erfolgen muss. Im Rahmen dieser Arbeit sind JavaBeans nicht weiter von
Interesse, sollen aber der Deutlichkeit halber an dieser Stelle aufgeführt sein, um Verwechslungen mit Enterprise-Beans vorzubeugen. Eine JavaBean ist nach [DP02] wie folgt definiert:
Definition 3.15 Eine JavaBean ist eine Java-Klasse, die folgende Eigenschaften unterstützt:
• Introspektion, d.h. eine JavaBean kann auf ihre Beschaffenheit hin analysiert werden
• Anpassbarkeit, d.h. ein Nutzer kann Aussehen und Verhalten der JavaBean beeinflussen
und anpassen
• Events als einfache Metapher zur Kommunikation von JavaBeans untereinander
• Persistenz, d.h. eine JavaBean kann angepasst, anschließend gesichert und wiederhergestellt werden
Die Schnittstelle zu einer JavaBean wird durch ihre Attribute, Methoden und Events beschrieben.
2
Die Methoden einer JavaBean folgen dabei einer spezifischen Namenskonvention. So existieren beispielsweise zu jedem Attribut der JavaBean eine getAttributname()- und eine setAttributname()-Methode zum Setzen bzw. Auslesen des Attributwertes. Die JavaBeans-Spezifikation
beschreibt die Programmierschnittstellen für das Erkennen und Nutzen von Eigenschaften der
Java Beans, die Anpassung dieser an individuelle Gegebenheiten, das Registrieren für und Senden von Events zwischen einzelnen JavaBeans und ihre Persistenz. Weitere Informationen zu
JavaBeans finden sich in [Sun97].
Demgegenüber steht der Begriff der Enterprise JavaBeans (EJB). EJB bezeichnet eine Komponenten-Architektur und ist Bestandteil des Java-2-Plattform, Enterprise Edition
(J2EE)-Konzeptes. Die Spezifikation der Enterprise JavaBeans zielt auf die Abbildung verteilter und transaktionsorientierter Geschäftsprozesse ab. Dabei beinhaltet die EJB-Architektur
den Teil der serverseitigen Anwendungslogik, die in Form von Komponenten, den EnterpriseBeans, ausgeführt ist. Die EJB-Architektur beschreibt zusätzlich die Schnittstellenspezifikationen, über die die Komponenten der Architektur, die Enterprise-Beans, referenziert werden
können.
Die Komponenten, die sog. Enterprise-Beans, lassen sich in Anlehnung an [DP02] wie folgt
definieren:
Definition 3.16 Enterprise-Beans, im Folgenden auch Beans genannt, sind in einem verteilten Szenario serverseitige Komponenten, die in der Komponenten-Architektur der Enterprise JavaBeans (EJB) zum Einsatz kommen. Enterprise-Beans definieren die Anwendungslogik, auf die die Client-Programme zugreifen.
2
37
38
Um eine Verbindung zwischen Beans, Enterprise JavaBeans und dem J2EE-Konzept zu schaffen, soll nun eine Einordnung der Beans und der EJB-Architektur in den Kontext des J2EEKonzeptes durchgeführt werden. Im Anschluss daran wird die EJB-Architektur vertieft betrachtet.
3.5.2. Die EJB-Architektur: Einordnung und Übersicht
Die Einordnung der EJB-Architektur in den Kontext des J2EE-Konzeptes ist in Abbildung 3.4
dargestellt. Der J2EE-Server stellt die Basis der EJB-Architektur dar. Er beinhaltet einen oder
mehrere EJB- oder Web-Container (siehe Glossar) und stellt verschiedene Basisdienste und
-Komponenten für die Container zur Verfügung.
Abbildung 3.4.: Einordnung der EJB-Architektur in den J2EE-Kontext (nach [DP02])
Der J2EE-Server muss dabei die folgenden Dienste, Funktionalitäten und Komponenten bereitstellen:
• Thread- und Prozessmanagement, um Parallelausführung mehrerer Container zu
ermöglichen
• Unterstützung von Clustering und Lastverteilung zur Skalierung der Rechenleistung über
mehrere Server
• Ausfallsicherheit
• Namens- und Verzeichnisdienst zur Lokalisierung von Komponenten
• Zugriffsmöglichkeit auf Betriebssystemkomponenten und deren Verwaltung
Angemerkt sei, dass J2EE und EJB keine fertigen Produkte, sondern lediglich Spezifikationen
darstellen. Es existieren daher diverse Umsetzungen dieser Spezifikationen, die sich voneinander unterscheiden. Somit gibt es beispielsweise keine einheitlichen Schnittstellen zwischen
Server und Container.
Nach Einordnung in den Kontext des J2EE-Konzeptes kann nun die genauere Betrachtung der
EJB-Architektur folgen. Abbildung 3.5 stellt diese mit allen dazugehörigen Komponenten dar.
Die unterschiedlichen Komponenten werden im Folgenden einzeln betrachtet und erläutert.
38
3.5 J2EE UND EJB
39
Abbildung 3.5.: Gesamtüberblick über die EJB-Architektur (nach [DP02])
3.5.3. Komponenten der EJB-Architektur
Wie in Abbildung 3.5 zu erkennen, basiert die EJB-Architektur auf verschiedenen Komponenten. Die Grundlage stellt der J2EE-Server dar, der den EJB-Container sowie verschiedene
Dienste und Schnittstellen zur Verfügung stellt. Diese Dienste und Schnittstellen können von
den Komponenten innerhalb des EJB-Containers genutzt werden und werden im nächsten Abschnitt aufgeführt und in ihrer Funktionalität beschrieben.
Dienste, Schnittstellen und Aufgaben des EJB-Containers
Zu den grundlegenden Schnittstellen, die der EJB-Container den darin enthaltenen Komponenten anbietet, zählen:
• API der J2SE (Java 2 Platform, Standard Edition: Beinhaltet eine vollständige Umgebung zur Anwendungsentwicklung auf dem Desktop und auf Servern. Näheres dazu
siehe [Sun04c].)
• API der Enterprise JavaBeans
• API des JNDI (Java Naming and Directory Interface: Bietet eine einheitliche Schnittstelle zu verschiedenen Namens- und Verzeichnisdiensten basierend auf Java. Näheres
dazu siehe [Sun04d].)
• API der JTA (Java Transaction API: Spezifiziert eine Standard-Schnittstelle zwischen
einem Transaktionsmanager und den Komponenten eines verteilten Systemes. Näheres
dazu siehe [Sun04e].)
• API der JDBC (Java Database Connectivity: Bietet Zugriff auf verschiedene SQLDatenbanken. Näheres dazu siehe [Sun04f].)
• API des JMS (Java Message Service: Erlaubt J2EE-Komponenten das Erzeugen, Versenden, Empfangen und Lesen von Nachrichten. Näheres dazu siehe [Sun04g].)
39
40
• API von JavaMail (JavaMail: Bietet ein plattform- und protokollunabhängiges Framework zur Erzeugung von Email- und Messaging-Anwendungen. Näheres dazu siehe
[Sun04h]).
• API von JAXP (Java API for XML Processing: Erlaubt es Anwendungen, XMLDokumente unabhängig von einer speziellen Implementierung eines XML-Prozessors
zu parsen und zu transformieren. Näheres dazu siehe [Sun04i].)
Der EJB-Container stellt eine Laufzeitumgebung für Enterprise-Beans dar und ermöglicht ihnen den Zugriff auf Applikationsserver-Komponenten. Diese stellen spezielle Dienste über
die soeben genannten Schnittstellen zur Verfügung. Zu den von diesen Komponenten zur
Verfügung gestellten Diensten zählen:
Namens- und Verzeichnisdienst Der Namensdienst wird verwendet, um es einem Client zu ermöglichen, eine Bean anhand von Metadaten aufzufinden. Es werden Referenzen auf entfernte Objekte unter einem frei definierbaren Namen an einem festgelegten
Platz im Namensdienst derart hinterlegt (Binding), dass sie über diesen Namen aufzufinden sind (Lookup). Ein Verzeichnisdienst erweitert die Funktionalitäten eines Namensdienstes dahingehend, dass die verwalteten Objekte in hierarchischen Strukturen
verwaltet und administriert sowie mit zusätzlichen Metadaten versehen werden können.
Durch den Umstand, dass auch Beans Informationen aus dem Namens- und Verzeichnisdienst beziehen können, wird über Parametrisierung eine Beeinflussung der Beans
von außen möglich. Zudem kann die Bean so auf Dienste wie z.B. Datenbankverbindungen oder Messaging-Dienste zugreifen. In dieser Komponente findet sich der Ansatz der Service-Registry eines Web-Services wieder, der zuvor bereits als vorteilhafte
Architektur-Eigenschaft identifiziert wurde. Der Zugriff auf den Namens- und Verzeichnisdienst erfolgt über die JNDI-Schnittstelle.
Transaktions-Monitor Der EJB-Container beinhaltet eine Dienstkomponente, die sich um
die Abwicklung von Transaktionen kümmert. Der sog. Transaktions-Monitor überwacht
alle Vorgänge, die Teil einer Transaktion sind, und sorgt bei Fehlschlagen dieser für das
Zurücknehmen der Teile der Transaktion, die bereits ausgeführt wurden. Der Container
zeichnet für die Verfügbarkeit transaktionaler Protokolle wie z.B. dem Zwei-PhasenSperr-Protokoll (siehe Glossar) verantwortlich. Die EJB-Spezifikation sieht dabei lediglich die Implementierung von flachen Transaktionen vor, die nicht ineinander geschachtelt werden können. Eine Bean kann Transaktionen explizit benutzen, indem sie direkt
mit dem Transaktionsdienst des EJB-Containers kommuniziert, oder aber deklarativ, indem bereits bei Installation der Bean im EJB-Container angegeben wird, welche Methoden innerhalb welcher Transaktion ablaufen sollen. Letzterer Fall erfordert bei der
Entwicklung der Bean keine Transaktionsimplementation, da der Container für die transaktionale Ausführung sorgt. Der Zugriff auf den Transaktions-Monitor erfolgt über die
JTA-Schnittstelle.
Datenbanken Datenbanken, die im Umfeld des J2EE-Servers vorhanden sind, lassen sich
über die JDBC-Schnittstelle ebenfalls ansprechen. Durch die Standardisierung des Zugriffes per JDBC wird der Zugriff auch auf heterogene Datenbanksysteme ermöglicht.
Messaging-Service Durch die Integration eines Messaging-Dienstes im EJB-Container
wird die Kommunikation zwischen Beans und damit die Parallelausführung ermöglicht.
Die Nachrichten können anonym und asynchron ausgetauscht werden, was den Vorteil
erbringt, dass keine Bean nach Versenden einer Nachricht blockiert wird, bis eine Antwort erfolgt. Zudem können so beliebige Partner miteinander kommunizieren. Zusätzlich
40
3.5 J2EE UND EJB
41
wird eine Möglichkeit geschaffen, Schnittstellen zu einzelnen Komponenten umzusetzen. Der Zugriff auf den Messaging-Service erfolgt über die JMS-Schnittstelle bzw. die
JavaMail-API.
Weitere Dienste Im Rahmen der Laufzeitumgebung werden zusätzlich weitere Dienste vom
Anbieter eines Java-Applikationsservers zur Verfügung gestellt:
• Kontrolle des Lebenszyklus einer Bean: Die Erzeugung, Zustandsüberführung
und das Löschen einer Bean ist Aufgabe des EJB-Containers.
• Instanzenpooling, Aktivierung und Passivierung von Beans: Diese Aufgaben
dienen der Steigerung der Performanz des Applikationsservers. Da in großen Umgebungen unter Umständen viele Beans zu verwalten sind, ist es von Vorteil, nur
aktive Beans im Speicher des Applikationsservers zu halten und inaktive Beans so
zu sichern, dass sie bei Inaktivität passiviert und auf Sekundärspeicher ausgelagert
und bei Bedarf wieder reinstantiiert werden können. Die Möglichkeit der Aktivierung und Passivierung von Beans ist jedoch vom Typ der Bean abhängig.
• Verteilung der Beans auf verschiedene Applikationsserver: Der EJB-Container
macht Enterprise-Beans für Clientprogramme verfügbar und kümmert sich zusätzlich um die Verteilung der Beans auf verschiedene Applikationsserver. Somit
können Eigenschaften wie z.B. Lastverteilung umgesetzt werden, indem Beans von
einem stark frequentierten auf einen weniger belasteten Applikationsserver verlagert werden können. Dabei kommen Technologien wie z.B. das Internet Inter-ORB
Protocol (IIOP) (siehe Glossar), oder Java Remote Method Invocation (Java RMI)
(siehe Glossar) zum Einsatz, auf die hier nicht weiter eingegangen wird.
• Persistenz: Um die Portierbarkeit von persistenten Komponenten zu verbessern,
wurde ein Persistenz-Dienst eingeführt, der eine automatische Persistenz bestimmter Komponenten ermöglicht. Der EJB-Container bestimmt dabei, wann eine Komponente geladen bzw. gespeichert wird. Eine bessere Portabilität resultiert aus dem
Umstand, dass die Durchführung der Speicherung sowie die Festlegung, an welchem Ort und wie eine Komponente gespeichert wird, vom Persistenz-Dienst, und
nicht von der Bean selbst übernommen wird. Somit kann eine Komponente ohne
Bedarf zur Anpassung von etwaigen Persistenzmethoden in ein anderes System mit
Persistence Manager portiert werden. Der Persistenz-Dienst kommuniziert mit dem
Speichermedium, auf das die Komponenten persistent ausgelagert werden. Die Abbildung einer Komponente auf ein vom Speichermedium zu verarbeitendes Format
erfolgt zum Zeitpunkt der Installation der Komponente (zur Installation einer Komponente siehe Abschnitt 3.5.4).
Eine zusätzliche Funktionalität des Persistenz-Dienstes besteht darin, Suchanfragen nach gespeicherten Komponenten zu formulieren. Dazu sieht die EJBSpezifikation die Abfragesprache EJB-QL (Enterprise JavaBeans Query Language) vor, mit Hilfe derer ein Auffinden von persistenten Komponenten ermöglicht
wird.
• Sicherheit: Der EJB-Container bietet ein Sicherheitsmanagement im Rahmen der
Laufzeitumgebung von Komponenten. Durch Ansiedlung des Konzeptes in der
Laufzeitumgebung und nicht in der Komponente wird eine einfache Wiederverwendbarkeit der Komponenten und Anpassbarkeit des Sicherheitskonzeptes von
außen erreicht. Das Sicherheitsmanagement erlaubt die Definition von Benutzerrollen und entsprechenden Rechten zum Aufruf von speziellen Methoden im Rahmen des Deployment-Deskriptors. Zugeteilt werden diese Rechte zum Zeitpunkt
der Bean-Installation. Weiterhin sieht die EJB-Spezifikation die Möglichkeit der
Authentifizierung eines Benutzers mit Benutzerkennung und Passwort sowie eine
41
42
gesicherte Kommunikation durch den Einsatz von SSL, einem Verschlüsselungsprotokoll, vor.
Komponenten innerhalb des EJB-Containers
Innerhalb des EJB-Containers existieren verschiedene Komponenten, die über die zuvor vorgestellten Schnittstellen auf die Dienste des EJB-Containers zugreifen können. Zu diesen Komponenten zählen:
Persistence Manager: Der Persistence Manager ist die Komponente, die für die Umsetzung der im Persistenz-Dienst formulierten Eigenschaften verantwortlich zeichnet. Über
die Implementierung eines Persistence Managers für eine Entity-Bean werden dieser alle
Eigenschaften des Persistenz-Dienstes zur Verfügung gestellt.
Enterprise-Beans: Die serverseitigen Komponenten der EJB-Architektur werden, wie in
Abschnitt 3.5.1 bereits erwähnt, als Enterprise-Beans bezeichnet. In ihnen ist die Anwendungslogik implementiert, auf die ein Client zugreifen kann. Eine Enterprise-Bean
wird in einem EJB-Container installiert, der eine Laufzeitumgebung für sie bereitstellt.
Dabei können Enterprise-Beans implizit und explizit auf die vom EJB-Container angebotenen Dienste zugreifen. Ein impliziter Zugriff erfolgt bei containergesteuerter Persistenz, bei deklarativen Transaktionen, beim Empfang asynchroner Nachrichten sowie in
den Aspekten des Sicherheitsmanagements. Explizite Zugriffe erfolgen bei Verwendung
expliziter Transaktionen, Bean-gesteuerter Persistenz sowie beim Versand asynchroner
Nachrichten.
Es lassen sich drei Ausprägungen von Enterprise Beans unterscheiden, die im Folgenden
als Bean-Typen bezeichnet werden.
• Session-Beans: Session-Beans dienen der Modellierung von Abläufen oder
Vorgängen. Ein Client kann auf die Methoden, die eine Session-Bean anbietet, zugreifen und deren Funktionalität nutzen. Dabei lassen sich zustandsbehaftete (stateful) und zustandslose (stateless) Session-Beans unterscheiden.
Zustandslose Session-Beans können keine Daten speichern, die in einem nachfolgenden Methodenaufruf zur Verfügung stehen würden. Daher stehen ihnen lediglich die Daten zur Verfügung, die als Parameter übergeben wurden. Aus der
Zustandslosigkeit resultiert, dass sich zustandslose Session-Beans gleichen Typs
nicht voneinander unterscheiden lassen, und dass dazu auch keine Notwendigkeit
besteht.
Zustandsbehaftete Session-Beans können im Unterschied zu zustandslosen Session Beans Daten über mehrere Methodenaufrufe hinweg speichern. Somit können
Aufrufe solcher Beans deren Zustand verändern, weshalb sie sich auch voneinander unterscheiden lassen. Die gespeicherten Daten gehen verloren, wenn ein Client
die Verbindung zur Bean trennt oder der sie beherbergende Server terminiert wird.
• Message-Driven-Beans: Message-Driven-Beans sind Empfänger von asynchronen Nachrichten, die von einer anderen Komponente über den Messaging-Dienst
versendet wurden. Im Gegensatz zu Session-Beans und Entity-Beans, die per
Remote- oder Local-Interface (näheres zu den Bestandteilen einer Bean siehe Abschnitt 3.5.3) synchron angesprochen werden können, können Message-DrivenBeans ausschließlich asynchron und direkt über einen bestimmten Kanal per
Messaging-Dienst angesprochen werden. Die Asynchronität hat den Vorteil, dass
der Client, der die Kommunikation aufgenommen hat, nicht auf Zustellung und
Abarbeitung der Nachricht warten muss, sondern direkt weiterarbeiten kann. Der
42
3.5 J2EE UND EJB
43
Container kann nun für verschiedene Kanäle jeweils eine Message-Driven-Bean
einsetzen, die alle Nachrichten auf dem jeweilig entsprechenden Kanal abarbeitet.
Message-Driven Beans sind zustands- und identitätslos.
• Entity-Beans: Entity-Beans dienen zur Abbildung von Entitäten der realen Welt,
also als eine Art Datentyp. Sie sind die Repräsentation der Daten, auf denen
Session-Beans arbeiten. Dabei ist die Mehrfachnutzung einer Entity-Bean-Instanz
durch verschiedene Clients möglich.
Es lassen sich zwei Arten von Persistenz bei Entity-Beans unterscheiden: man
spricht von einer bean-managed Persistence, wenn die Bean selbst für die persistente Sicherung der Daten verantwortlich zeichnet. Im Falle, dass der EJBContainer die persistente Sicherung einer Entity-Bean organisiert, spricht man von
einer container-managed Persistence.
Da von Entity-Beans zur Laufzeit unterschiedliche Instanzen existieren können,
lassen diese sich über einen eindeutigen Identifikator, einen Primärschlüssel, referenzieren. Dieser wird ihnen vom EJB-Container zugewiesen und ist von außen
einsehbar.
Die Schnittstelle zwischen einer Entity-Bean und dem EJB-Container
ist der sog. Kontext (javax.ejb.EJBContext). Dabei handelt es
sich um ein Interface, welches für den jeweiligen Bean-Typ spezialisiert wird (im Falle der Entity-Bean zu javax.ejb.EntityContext,
in den anderen Fällen zu javax.ejb.MessageDrivenContext bzw.
javax.ejb.SessionContext). Ein solcher Kontext bleibt mit einer Bean
während ihrer gesamten Lebensdauer assoziiert.
In Tabelle 3.1 werden die drei Bean-Typen noch einmal bezüglich verschiedener Eigenschaften
gegenübergestellt.
Bestandteile einer Enterprise-Bean
Die Komponenten, aus denen Beans bestehen, seien im Folgenden aufgeführt:
• Remote- und (Remote-)Home-Interface oder
• Local- und Local-Home-Interface (Entity- und Session-Beans)
• Bean-Klasse (alle Bean-Typen)
• Primärschlüssel oder Primärschlüsselklasse (Entity-Beans)
• Deployment-Deskriptor (alle Bean-Typen)
Ausführliche Beispiele für die Implementierung dieser Bestandteile werden in Anhang A anhand von Sourcecode-Ausschnitten aufgeführt.
Je nachdem, ob eine Entity- oder Session-Bean mit einer anderen Bean innerhalb des selben
oder eines anderen EJB-Containers kommuniziert, wird das Local- oder Remote-Interface genutzt. Man spricht im ersten Fall unter Nutzung des Local-Interfaces von einem Local-ClientView, im zweiten Fall unter Nutzung des Remote-Interfaces vom Remote-Client-View. Da EJB
eine Architektur für verteilte Komponenten darstellt, wird meistens eine Kommunikation über
das Remote-Interface durchgeführt.
43
44
S ESSION -B EAN
M ESSAGE -D RIVEN B EAN
E NTITY-B EAN
Aufgabe
der Bean
Nutzung
für
einen
Dienst, der Aufgaben für einen Client
ausführen soll.
Nutzung für serverseitige Verarbeitung asynchroner Nachrichten.
Nutzung zur dauerhaften Speicherung eines
Objektes.
Zugriff
auf die
Bean
Private Ressource, die
dem Client exklusiv zur
Verfügung steht.
Kein
direkter
Zugriff durch den Client
möglich. Einzige Kommunikationsmöglichkeit
mit dem Client über
den Messaging-Dienst
durch Verschicken von
Nachrichten auf einem
bestimmten Kanal.
Zentrale Instanz, die
von mehreren Clients
genutzt werden kann
und deren Daten allen
Clients zur Verfügung
stehen.
Persistenz Nicht persistent.
der Bean Datenverlust bei Terminierung von verbundenem Client oder hostendem Server.
Nicht persistent.
Datenverlust bei Terminierung des hostenden
Servers. Noch nicht
zugestellte
Nachrichten können hingegen
persistent sein.
Persistent.
Bei Terminierung der
verbundenen
Clients
oder des hostenden
Servers befindet sich
der Zustand der Bean
auf einem persistenten
Speichermedium,
so
dass die Bean zu einem
späteren Zeitpunkt wiederhergestellt werden
kann.
Tabelle 3.1.: Gegenüberstellung der drei Bean-Typen (nach [DP02])
3.5.4. Implementierung und Verwendung einer Bean
Die Implementierung einer Bean bedarf mehrerer Schritte, die sich je nach Bean-Typ voneinander unterscheiden. Die Implementierung einer Session- oder Entity-Bean erfordert zunächst
die Implementierung der Remote- und Home- bzw. Local- und Local-Home-Interfaces. Bei
allen drei Bean-Typen bedarf es zusätzlich der Implementierung der Bean-Klasse und des
Deployment-Deskriptors. Soll eine Entity-Bean implementiert werden, muss zusätzlich die
Primärschlüsselklasse umgesetzt werden. Beispiele für konkrete Implementierungen der Interfaces und Klassen sind in Kapitel 7 einzusehen.
Nach Implementierung dieser Klassen, Interfaces und Deskriptoren werden diese in einem jarArchiv verpackt, welches sich mit Hilfe der Werkzeuge, die der Hersteller des EJB-Containers
zur Verfügung stellt, im EJB-Container installieren lässt. Aussehen und Funktionalität dieser
Werkzeuge differieren von Hersteller zu Hersteller und sind nicht standardisiert. Erforderlich
ist jedoch, dass nach Installation des Bean-jar-Archives alle zur Ausführung der Bean fehlenden Komponenten vorhanden sind. Zu diesen Komponenten zählen die Implementierung des
Home- und Remote- bzw. des Local-Home- und Local-Interfaces und die Implementierung
der konkreten Bean-Klasse. Weiterhin wird die Bean anhand der im Deployment-Deskriptor
angegebenen Informationen im Container registriert. Dies beinhaltet unter Anderem das Eintragen der Bean und ihrer spezifischen Eigenschaften in den Namens- und Verzeichnisdienst
44
45
des Containers.
Wenn nun ein Client eine Bean verwenden möchte, kann er diese über die JNDI-Schnittstelle
des Namens- und Verzeichnisdienstes auffinden und so Zugriff auf sie erlangen. Der Container
stellt dem Client anschließend einen Client-Stub der Implementierung des Home-Interfaces zur
Verfügung. Über diesen Client-Stub kann der Client eine Bean erzeugen. Daraufhin wird dem
Client ein Stub des Remote-Interfaces zur Verfügung gestellt, über den er auf alle Methoden
der Bean zugreifen kann. Somit ist die Nutzung der Bean für den Client in vollem Umfang
ermöglicht.
In diesem Kapitel erfolgte in Abschnitt 3.1 zunächst die Klärung der Grundlagen zum Thema Architekturen. Anschließend wurden in Abschnitt 3.2 verschiedene Ansätze und Konzepte
von Software-Architekturen vorgestellt und bezüglich ihrer Eigenschaften miteinander verglichen. Die Ergebnisse dieser Untersuchungen, die in Abschnitt 3.3 formuliert wurden, wurden
in Hinblick auf die Eignung der verschiedenen Ansätze und Konzepte für die Architektur betrachtet, die im Kontext dieser Arbeit konzeptioniert und implementiert werden soll. Dabei
wurden verschiedene Konzepte und Ansätze identifiziert, die in die zu konzeptionierende Architektur einfließen können. Es stellte sich heraus, dass lediglich einzelne Aspekte der vorgestellten Konzepte und Ansätze sinnvoll Verwendung finden können. Die Entscheidung zur
umfassenden Implementierung ausschließlich eines Konzeptes oder Ansatzes konnte nicht getroffen werden. Die als wünschenswert identifizierten Eigenschaften der Konzepte und Ansätze
seien im Folgenden aufgeführt.
So ist eine umfassende Vernetzung von Komponenten und Operatoren mit- und untereinander
vonnöten, da in einem verteilten Szenario an unterschiedlichen Orten gehaltene Daten für entfernt lokalisierte Komponenten und Operatoren verfügbar sein müssen. Im Hinblick darauf ist
es vorteilhaft, eine strukturierte, standardisierte Kommmunikation zu ermöglichen, um einheitliche Zugriffsschnittstellen auf die verteilten Komponenten der Datenhaltung und -verarbeitung
zu schaffen und die Vernetzung der Komponenten sowie die Erweiterung um zusätzliche Komponenten somit zu erleichtern. Dadurch ist gewährleistet, dass sämtliche im Gesamtsystem
vorhandenen Informationen für alle Komponenten und Operatoren verfügbar sind.
Auch die Implementierung einer Service-Registry, die einen Überblick über die durch die Komponenten angebotenen Dienste bietet, ist als wünschenswerte Eigenschaft des Gesamtsystemes
identifiziert worden. Durch einen Überblick über die angebotenen Dienste wird ein zusätzlicher Grad an Übersichtlichkeit geschaffen, der bei der Konzeption neuer Analysen von Nutzen
sein kann.
Schließlich ist der Einsatz des Container-Konzeptes als vorteilhaft identifiziert worden, da potentiell vom Container angebotene Dienste für verschiedene Zwecke genutzt werden können,
ohne sie neu implementieren zu müssen. Ein Beispiel für einen Dienst, der von einem Container angeboten werden könnte, ist ein Dienst, der die Kommunikation zwischen verteilten
Komponenten ermöglicht. Diese könnte beispielsweise über eine vorgegebene Kommunikationsschnittstelle beherbergender Container realisiert werden. Somit wäre eine standardisierte, strukturierte Kommunikationsschnittstelle, die zuvor bereits als wünschenswert identifiziert
wurde, mit wenig Implementierungsaufwand verfügbar. Weitere Dienste, die von einem Container angeboten werden könnten, sind ebenfalls denkbar und vorteilhaft einsetzbar.
Folgend auf die Identifikation wünschenswerter Konzepte, Ansätze und Eigenschaften fand
in Abschnitt 3.4 eine Untersuchung bereits verfügbarer Implementierungen von Architekturen bezüglich der Kompatibilität zu den als verwendenswert identifizierten Konzepten und
45
46
Ansätzen sowie bezüglich ihrer Eignung im Hinblick auf die Vorgaben des ReKlaMe-Projektes
statt. Die EJB-Architektur aus dem J2EE-Konzept wurde auf Basis dieser Untersuchungen als
zu verwendende Architektur ausgewählt. Ihr Aufbau wurde anschließend in Abschnitt 3.5 detailliert beschrieben.
Gründe für den Einsatz der EJB-Architektur liegen hauptsächlich in der umfangreichen Unterstützung der Verteiltheit von Komponenten und Operatoren. Auch der Umstand, dass die
EJB-Architektur als die Standard-Architektur für die Erstellung verteilter Geschäftsanwendungen auf Basis der Programmiersprache Java angesehen wird [DP02] und zahlreiche der
zuvor als wünschenswert identifizierten Eigenschaften, Konzepte und Ansätze umsetzt bzw.
ermöglicht, führte zur Entscheidung für den Einsatz der EJB-Architektur.
Durch die in Kapitel 2 und 3 vorgestellten Konzepte, Ansätze und Technologien wurden somit
die Grundlagen für den konzeptionellen Teil dieser Arbeit geschaffen, so dass im folgenden
Kapitel mit der Konzeptionierung des Ausführungsmodelles begonnen werden kann, aus welchem anschließend die zu implementierende Architektur abgeleitet wird.
46
4. Ein Ausführungsmodell für
ReKlaMe-Analysen
Nachdem in den vorherigen Kapiteln die Klärung grundlegender Begriffe stattgefunden hat,
folgt nun der konzeptionelle Teil dieser Arbeit. Zunächst muss ein Ausführungsmodell konzeptioniert werden, welches die im ReKlaMe-Szenario zu identifizierenden Operatoren beinhaltet
und die Daten- und Kontrollflüsse zwischen ihren Operatoren festlegt.
In diesem Kapitel werden in Abschnitt 4.1 zunächst erneut die Zielsetzungen des ReKlaMeProjektes aufgegriffen. Die Rahmenbedingungen des Szenarios im Kontext des ReKlaMeAnsatzes werden identifiziert. Anschließend erfolgt in Abschnitt 4.2 die Identifikation aller
Abläufe und Phasen der Analysen, die im Rahmen des ReKlaMe-Ansatzes durchgeführt werden können. In Abschnitt 4.3 werden dann die Operatoren, die den Abläufen zugrunde liegen,
identifiziert und formal spezifiziert. Schließlich wird in Abschnitt 4.4 eine Verbindung zwischen den Operatoren geschaffen, so dass die in 4.2 identifizierten Abläufe unter Berücksichtigung der in 4.3 formalisierten Operatoren formal beschrieben und in Form von Abbildungen
formuliert werden können.
4.1. ReKlaMe revisited - Zielsetzungen, Umgebung,
Rahmenbedingungen
Die Intention des Dissertationsprojektes ReKlaMe von Herrn Heiko Tapken [Tap04] wurde
bereits in Abschnitt 1.1 grob skizziert. Diese soll an dieser Stelle noch einmal aufgegriffen und
anhand weiterer Rahmenbedingungen und möglicher Einsatzszenarien näher motiviert werden.
Für viele betriebswirtschaftliche Fragestellungen erweisen sich manuelle Datenanalysen u.a.
aufgrund der Größe der zur Entscheidungsfindung heranzuziehenden Datenmengen als nicht
adäquat. Aus diesem Grund werden in der Praxis zunehmend automatisierte Verfahren aus
dem Bereich des KDD zur Entdeckung von Informationen in Form von Mustern mit Erfolg
eingesetzt. Der ReKlaMe-Ansatz verfolgt das Ziel, Analysten mit Datenbank-Kenntnissen bei
der Durchführung komplexer Analysen zu unterstützen.
Zwischen der Repräsentation unternehmerischer Daten (oftmals in Form relationaler DataWarehouse-Schemata) und den von traditionellen Data Mining-Verfahren benötigten Formate (CSV-, ARFF-Dateien u.ä.) existiert ein Bruch. Durch replikationsbasierte Transformationen sowie durch Techniken der Propositionalisierung, wie sie z.B. im Kontext der induktiven
Logik-Programmierung zur Anwendung kommen, werden Qualitätsaussagen (z.B. bzgl. Data
Lineage) erschwert, und ein Semantikverlust entsteht. Jede wiederkehrende Datenanalyse erfordert eine erneute Datentransformation, so dass iterative Datenanalysen erschwert und auf
temporalen Datenbanken basierende Datenanalysen nahezu unmöglich gemacht werden. Im
Falle iterativer Analysen betrifft dies im schlechtesten Fall sogar jeden Datenanalyseschritt.
Ferner geht die für Datenbank-Spezialisten gewohnte strukturierte Repräsentation von Daten (in diesem Falle die der Muster) verloren. Der ReKlaMe-Ansatz ermöglicht es, komplexe
Klassifikationsaufgaben direkt auf temporalen relationalen Data Warehouses ansetzend itera-
47
48
K APITEL 4 - E IN AUSF ÜHRUNGSMODELL F ÜR R E K LA M E -A NALYSEN
tiv durchzuführen und Muster auf Grundlage des multirelationalen Data Mining-Frameworks
[KBSvdW99] in Form von Entscheidungsbäumen zu repräsentieren.
Bei vielen Fragestellungen, deren Lösungen durch die Anwendung von Data Mining Verfahren unterstützt werden könnten, bietet sich eine firmenübergreifende, kooperierende Analyse
von Daten an. So sind z.B. Banken daran interessiert, Scheck- oder Kreditkartenbetrüger ausfindig zu machen. Um dieses Ziel zu erreichen, bietet sich das Erlernen eines gemeinsamen
Klassifikators z.B. in Form eines Entscheidungsbaumverfahrens an. Während bei klassischen
kooperativen Datenanalysen oftmals eine a priori-Integration der Daten durchgeführt wird, ist
dies hier aufgrund von Datenschutzbestimmungen nicht möglich. Ferner wird jedes Kreditinstitut darauf bedacht sein, zusätzlich für das jeweilige Einzelunternehmen verfeinerte Modelle
abzuleiten, um daraus Wettbewerbsvorteile zu erlangen. Ziel des ReKlaMe-Ansatzes ist es,
auch derart gestaltete, verteilte temporale Datenanalysen zu unterstützen.
Auf Grundlage dieser Zielsetzungen und Rahmenbedingungen sollen nun mögliche AnalyseAbläufe des ReKlaMe-Ansatzes anhand von noch zu identifizierenden Operatoren und den zugehörigen Kontroll- und Datenflüssen konzeptioniert und in Form eines Ausführungsmodelles
umgesetzt werden.
4.2. Abläufe und Phasen einer ReKlaMe-Analyse
In diesem Abschnitt wird die Beschreibung des Funktionsumfanges des ReKlaMe-Projektes
aus analytischer Sicht betrachtet. Dabei werden verschiedene Operatoren identifiziert und
drei alternative Analyse-Abläufe aufgezeigt. Es erfolgt die Beschreibung aller Komponenten, Operatoren, Kontroll- und Datenflüsse, die zur Durchführung eines Analyse-Ablaufes im
ReKlaMe-Kontext benötigt werden.
4.2.1. Grundsätzliche Betrachtungen
ReKlaMe ermöglicht die Durchführung von Analysen aus dem Bereich der Klassifikation
direkt auf verteilten oder nicht verteilten multirelationalen Datenquellen, ohne diese zuvor
physisch oder virtuell in einen zentralen Datenbestand integrieren zu müssen. Physische Integration sieht hier die Zusammenführung der zugrunde liegenden Tupel in einer Relation
vor. Virtuelle Integration bezeichnet demgegenüber die Vereinigung der Daten ohne physische
Zusammenführung, also beispielsweise in der Ausführung einer Methode oder Funktion eines Software-Programmes. Um die Durchführung verteilter Analysen direkt auf den verteilten
Datenquellen zu ermöglichen, bedarf es einer Modularisierung der zentralen Analyseaufgabe.
Diese Modularisierung kann semi-automatisch erfolgen. Zudem muss untersucht werden, ob
die Modularisierung an zentraler oder dezentraler Stelle durchgeführt werden soll oder ob eine
Mischform beider Ansätze zu bevorzugen ist. Die Grundlage der Durchführung von Analysen
stellen Metadaten dar, anhand derer Analysen modularisiert und ausgeführt werden können.
Analysen werden von einer zentralen Stelle aus initiiert. Zu den Datenquellen, auf denen sie
ausgeführt werden können, zählen temporale relationale Datenbanken und Data Warehouses.
Bezüglich der Ausführung von Analyse-Abläufen muss zwischen synchronen und asynchronen Analysen unterschieden werden. Eine Entscheidung für eine der beiden Alternativen kann
anhand des Zeitbedarfes mehrerer parallel auszuführender Analysen getroffen werden. Zu
berücksichtigen ist hier, dass eine möglichst optimale Ausnutzung der vorhandenen AnalyseOperatoren gewährleistet werden sollte. Asynchrone Analysen belegen eine Ressource nur für
die Analysezeit, die sie selbst für eine lokale Teilanalyse auf einer Datenquelle benötigen. Im
Falle von synchronen Analysen wird die Analysezeit hingegen im schlechtesten Fall durch den
48
4.2 A BL ÄUFE UND P HASEN EINER R E K LA M E -A NALYSE
49
Zeitbedarf der langsamsten Analyse bestimmt, so dass Quellen, die schnell zum Analyseziel
gelangt sind, trotzdem bis zu dem Zeitpunkt, zu dem die langsamste Analyse durchgeführt
wurde, blockiert sind. Hier kann eine Steuerung konzeptioniert werden, die eine entsprechende Entscheidung für eine synchrone oder asynchrone Analyseausführung treffen und umsetzen
kann. Sollten sich die Analyse-Module in ihrer Ausführungszeit hingegen kaum unterscheiden,
so kann kaum Nutzen aus der asynchronen Ausführung von Analysen gezogen werden. Als Ansatz für asynchrone Analysen lassen sich datenoder ereignisgetriebene Ansätze verwenden,
und auch eine Mischform dieser beiden Ansätze ist denkbar.
Ein weiterer, nicht zu unterschätzender Aspekt liegt in der Rechtebehandlung bezüglich des
Zugriffes auf die Daten in den verteilten Datenquellen. Es existieren grundsätzlich drei unterschiedliche Arten von Datenquellen. Die Daten, die in diesen Datenquellen gehalten werden,
unterscheiden sich bezüglich ihrer Datenschutzrichtlinien voneinander, wobei drei Richtlinien
zu identifizieren sind:
1. Öffentliche Daten: Alle Daten einer öffentlichen Datenquelle sind für jedermann einsehbar, es existieren keine Einschränkungen bezüglich der Leserechte auf der Datenquelle. Die Ergebnisse einer Analyse auf Basis der Daten einer solchen Datenquelle sind im
Allgemeinen öffentlich verfügbar und uneingeschränkt einsehbar, es können jedoch auch
Restriktionen auferlegt werden, um Analyseergebnisse beispielsweise aus kommerziellen Gründen zu schützen.
2. Partiell geschützte Daten: Teile der Daten einer Quelle dieser Art sind für jedermann
einsehbar, es existieren jedoch Einschränkungen bezüglich der Leserechte bestimmter
Attribute, Tupel oder ganzer Relationen. Die Ergebnisse einer Analyse auf Basis der
Daten einer solchen Datenquelle können selektiv eingesehen werden.
3. Geschützte Daten: Die Daten dieser Quelle sind ausschließlich mit Authentifizierung
oder gar nicht einsehbar. Die Ergebnisse einer Analyse auf Basis einer solchen Datenquelle sind hingegen selektiv einsehbar.
Schreibender Zugriff auf die Datenquellen wird vorerst nicht erlaubt. Denkbar ist, Analyseergebnisse als Attribut in den Quellrelationen zu speichern, jedoch müssen dazu abhängig von
den Analyseergebnissen die Quellrelationen verändert werden. Alternativ zu einem solchen
Ansatz kann die Speicherung der Analyseergebnisse an anderer Stelle erfolgen. Aufgrund der
zeitlichen Vorgaben und der nicht erheblichen Relevanz für den Kontext dieser Arbeit wird von
einer Speicherung der Ergebnisse in den Quellrelationen abgesehen.
Es können beliebig viele Datenquellen existieren, die einer der drei oben beschriebenen
Ausführungen entsprechen. Bezüglich der selektiven Einsicht in die Analyseergebnisse von
partiell oder vollständig geschützten Datenquellen müssen Strukturen geschaffen werden,
die eine Freigabe oder eine Sperrung der Einsicht in die Ergebnisse ermöglichen. Mögliche
Ansätze sind in Authentifikationsmechanismen, Anonymisierung oder in der manuellen Freigabe spezifischer Analyseergebnisse durch den Besitzer der der Analyse zugrunde liegenden
Daten zu finden. Der Ansatz der Anonymisierung kann beliebig komplex betrachtet werden
und ist im Rahmen dieser Arbeit daher nicht umsetzbar.
Eine Grundlage der Analysen bilden die Metadaten, die auf verschiedene Arten verwaltet werden können. So existieren die Möglichkeiten der zentralen oder dezentralen Metadatenverwaltung. Auch eine Mischform beider Ansätze ist denkbar. Zudem stellt sich die Frage, wie ein Anwender an die Metadaten gelangen kann, um eine Analyse zu planen und ausführen zu können.
Auch hier ist die exakte Umsetzung einer Metadaten-Verwaltung nicht Gegenstand dieser Arbeit, sondern die Funktionalität ist lediglich als exemplarische Komponente zu berücksichtigen
und in den Kontext der Architektur einzubetten.
49
50
Ein weiterer Aspekt ist die Beachtung temporaler Versionierung von Ressourcen. Eine minimale zeitliche Versionierung der Datenquellen, der erzeugten Modelle sowie der Metadaten
ist hier denkbar. Dazu kann eine attributbasierte Zeitstempelung eingeführt werden, bei der
zwischen Transaktions- und Gültigkeitszeit unterschieden werden kann. Für jede Art der Zeitbetrachtung werden zwei Zeitstempel vorgesehen: einer zur Speicherung des Anfangs- und
einer zur Speicherung des Endzeitpunktes. Der Transaktionszeitanfang (TZA) repräsentiert den
Zeitpunkt, zu dem ein Datensatz erzeugt wird. Das Transaktionszeitende (TZE) steht für den
Zeitpunkt, an dem ein Datensatz gelöscht werden soll. Der Unterschied zum normalen Vorgehen der Datenhaltung ohne temporale Zeitstempelung besteht bei der Verwendung von Transaktionszeitstempeln darin, dass anstelle der Löschung eines Datensatzes dieser lediglich als
gelöscht markiert wird, indem das Attribut TZE mit einem Wert belegt wird. Den bezüglich der
Transaktionszeit aktuellen Datensatz kann man anhand eines leeren TZE-Attributes identifizieren. Die zuvor vorhandenen Datensätze sind jedoch zusätzlich noch verfügbar. Zu beachten ist
hier, dass die Transaktionszeiten mit in den Primärschlüssel einzubeziehen sind, um eine Unterscheidung der Datensätze unterschiedlicher Zeitpunkte gewährleisten zu können, da sie sich
mit Ausnahme der Werte der Zeitstempel nicht voneinander unterscheiden. Die Gültigkeitszeit
repräsentiert das Zeitintervall, in dem ein Datensatz in der realen Welt Gültigkeit besitzt. Ein
Beispiel für Gültigkeitszeitstempel wäre der Zeitraum eines Zeitschriften-Abonnements, der
unabhängig vom Zeitpunkt des Anlegens des Datensatzes durch die Attribute Gültigkeitszeitanfang (GZA) und Gültigkeitszeitende (GZE) bestimmt werden kann. Durch Einführung dieser
Zeitstempel könnten Analysen im ReKlaMe-Kontext bezüglich temporaler Aspekte versioniert
werden. Grundlage einer derartigen Zeitstempelung ist jedoch eine Datensenke, die diese Attribute gemeinsam mit den Analyseergebnissen speichern kann.
4.2.2. Identifikation der Abläufe und Phasen
Bei näherer Betrachtung lassen sich die Analysen, die im Rahmen des ReKlaMe-Ansatzes
ermöglicht werden sollen, grob in drei Abläufe kategorisieren. So sollen Klassifikatoren auf
Basis verteilter Datenquellen induziert werden können. Weiterhin sollen sich die erzeugten
Klassifikatoren auf verteilten Datenquellen zur Klassifikation anwenden lassen. Schließlich ist
eine Art Wartung der erzeugten Klassifikatoren vorgesehen. Im Rahmen einer Wartung können
Klassifikatoren auf Basis neuer Trainingsdaten erweitert oder komplett durch neue ersetzt werden. Die identifizierten Abläufe sind in Abbildung 4.1 dargestellt. Im Folgenden sollen die
verschiedenen Phasen der drei Analyse-Abläufe näher betrachtet werden.
Abbildung 4.1.: Identifizierte Abläufe im Rahmen von ReKlaMe: Induktion, Klassifikation und
Wartung
50
51
Induktion von Klassifikatoren
Zunächst wird die Klassifikator-Induktion untersucht. Es lassen sich unterschiedliche AnalysePhasen identifizieren. So können Klassifikatoren lokal induziert werden. Eine Menge von Operatoren, die in diesem Kontext im Vordergrund stehen, ist die der Klassifikator-InduktionsOperatoren. Sie dienen der Ermittlung von Basisklassifikatoren und werden im Folgenden auch
als Lerner bezeichnet. Der Vorgang der Induktion eines Klassifikators sei folgend als Lernen
bezeichnet. Es können zwei Ausprägungen von Lernern unterschieden werden:
1. Lerner, die einen Klassifikator auf Basis einer Menge von Daten aus einer Quelle erzeugen. Das Vorgehen eines solchen Lerners ist in Abbildung 4.2a) schematisch dargestellt.
2. Lerner, die auf Basis einer Menge von Daten einer Quelle und einem Basisklassifikator inkrementell einen neuen Basisklassifikator erzeugen. Das Vorgehen eines solchen
Lerners zeigt Abbildung 4.2b).
Abbildung 4.2.: Lerner auf a) einer Datenquelle und b) inkrementell auf einer Datenquelle und
einem Basisklassifikator
Das Meta-Lernen ist eine weitere Phase des Lernens. Abbildung 4.3 skizziert diesen Ablauf. Dabei erzeugt der Meta-Lerner aus der Eingabe von Basisklassifikatoren einen MetaKlassifikator, der auf den Ergebnissen der Anwendung der Basisklassifikatoren beruht. Im Rahmen des ReKlaMe-Ansatzes sollen alle gängigen Meta-Lern-Verfahren zum Einsatz kommen.
Dazu zählen u.a. Kombinierer auf Basis der Verfahren Bagging (zu Bagging siehe [Bre96]),
Boosting (zu Boosting siehe [Sch90]), Arbiting (zu Arbiting siehe [CS93]) und sog. Statistical Combiner. Es soll also zusammenfassend eine Unterstützung von Daten- und ModellKombinierern im Rahmen dieser Arbeit realisiert werden. Meta-Lernen kann entweder auf einem physisch oder virtuell integrierten Datenbestand ausgeführt werden, oder aber verteilt auf
verschiedenen Datenquellen. Dazu wird der Vorgang des Meta-Lernens nicht zentral, sondern
an verschiedenen Orten durchgeführt. Grundlage eines derartig verteilten Meta-Lern-Prozesses
ist die Mobilität des Meta-Lerners oder die Kommunikation der Basisklassifikatoren zwischen
redundant vorgehaltenen Meta-Lernern an den jeweiligen Datenquellen. Weitere Meta-LernVerfahren werden in [Pre05] vorgestellt. Da sich die Ein- und Ausgabedaten dieser Verfahren
nicht voneinander unterscheiden, wird an dieser Stelle nicht weiter darauf eingegangen.
51
52
Abbildung 4.3.: Meta-Lerner
Im Rahmen der Grundlagen wurden in den Abschnitten 2.2.2 und 2.2.3 zwei Herangehensweisen an die Klassifikator-Induktion vorgestellt: die Task-Parallelisierung und die DatenParallelisierung. Die Analysen im ReKlaMe-Kontext werden auf verteilten Datenquellen ausgeführt, so dass sich beide Herangehensweisen sowohl beim Lernen als auch in der Anwendung
von Klassifikatoren nutzen lassen. Auch eine Kombination wäre denkbar. Die Integration der
verteilten Daten und Analyseergebnisse kann physisch oder virtuell erfolgen. Im Rahmen dieser Arbeit werden die Ansätze zur Parallelisierung der Induktion und Anwendung vom Klassifikatoren prototypisch betrachtet.
Die erzeugten Basisklassifikatoren können alternativ zu den bisher vorgestellten Lern- und
Meta-Lernverfahren in einer weiteren Phase dem ausführenden Benutzer an zentraler Stelle
präsentiert werden. Somit könnte der Benutzer diese zur weiteren Anwendung für Klassifikationen nutzen oder die Weiterverarbeitung dieser nach manueller Prüfung der Güte initiieren.
Anwendung von Klassifikatoren
Abbildung 4.4.: Verteilte Klassifikation ohne virtuelle oder physische Integration der Instanzen
Bezüglich der zweiten Art eines möglichen Ablaufes der Analysen im ReKlaMe-Ansatz, der
Anwendung der erzeugten Klassifikatoren, soll es ermöglicht werden, Klassifikatoren direkt
auf verteilten Datenbeständen anzuwenden, ohne dass eine virtuelle oder physische Integration
dieser Datenbestände im Vorfeld vonnöten ist. Dabei sollen auch komplexe Klassifikationen
52
53
unterstützt werden. Dieser Ablauf ist in Abbildung 4.4 dargestellt. Analog zu den Lernverfahren sind hier verschiedene Ansätze des verteilten Anwendens der Klassifikatoren zu unterscheiden. So können identische Analyseprozesse auf den verschiedenen Datenquellen zeitgleich Analysen durchführen und ihre Ergebnisse an eine zentrale Instanz senden, die diese
Klassifikationsergebnisse vereinigt. Ein solches Vorgehen entspricht dem Ansatz der DatenParallelisierung, die in Abschnitt 2.2.3 eingeführt wurde. Auch die serialisierte Anwendung
eines mobilen Klassifikators ist denkbar, der die Quellen der Reihe nach einzeln besucht, um
dort eine Klassifikation der Eingabeinstanzen durchzuführen.
Abbildung 4.5.: Verteilte Klassifikation ohne virtuelle oder physische Integration der Instanzen
für Klassifikatoren, die auf mehreren Quellen induziert wurden
Wurde ein Klassifikator auf Basis der Trainingsdaten mehrerer Quellen induziert, so ist die
Verfügbarkeit der Daten der bei der Induktion beteiligten Quellen für die Anwendung unabdingbar. So können Attribute, die im Klassifikator getestet werden, nur in den Instanzen einzelner Quellen auftreten, so dass zur Anwendung eines solchen Klassifikators die Daten all dieser
Quellen verfügbar sein müssen, um eine entsprechende Klassifikation durchführen zu können.
Würden diese Daten nicht vorliegen, so könnten die zu klassifizierenden Instanzen nicht weiter
in Klassen eingeteilt werden, und die Klassifikation würde frühzeitig ein Ende finden. Abbildung 4.5 zeigt dieses Vorgehen exemplarisch anhand der Durchführung einer Klassifikation an
einer Datenquelle, wobei der anzuwendende Klassifikator auf Basis der Daten der Quellen 1
bis n induziert wurde.
Alternativ ist ein ganz anderer Weg denkbar: Aus den Modellen der Klassifikatoren können
Selection Graphs abgeleitet werden. Diese können, sofern die Daten in relationalen Quellen
liegen, in Datenbankabfragen (beispielsweise SQL-Statements) gewandelt werden. Mit Hilfe
dieser Datenbankabfragen können dann die Instanzen einer Zielklasse direkt aus den verteilten
Datenbanken angefordert werden. Somit wird die Anwendung eines Klassifikators umgangen,
und die zu klassifizierenden Instanzen lassen sich sehr performant in ihre Zielklassen einteilen.
Dieser Ablauf ist in Abbildung 4.6 dargestellt. Auch hier ist die Vereinigung der Teilergebnisse
der Datenbankabfragen denkbar, um ein Gesamtergebnis zu erhalten. Für nähere Informationen bezüglich Selection Graphs, den Prozessen zur Wandlung von Entscheidungsbäumen in
Mengen von Selection Graphs sowie die Ableitung von SQL-Statements aus Selection Graphs
sei auf [Saa04] verwiesen. Dieser Ansatz wird prototypisch Unterstützung finden.
Wartung von Klassifikatoren
Im Rahmen der dritten Art eines möglichen Ablaufes der Analysen im ReKlaMe-Ansatz, der
Wartung, ist die Invalidierung von Klassifikatoren sowie die Initiierung der Neugenerierung
53
54
Abbildung 4.6.: Verteilte Klassifikation durch Erzeugung von Selection Graphs und Wandeln
in Datenbankabfragen
oder Erweiterung von Klassifikatoren vorgesehen. Es sei vorgegeben, dass der zu wartende
Klassifikator vorliegt und bezüglich des Meta-Lern-Vorganges jedesmal eine vollständige Neuberechnung des globalen Klassifikators durchgeführt wird. Diesbezüglich kann auf Basis von
neuen Daten oder zusätzlichen Attributen eine erneute Klassifikator-Induktion durchgeführt
werden, wobei die vorhandenen, und auf alten Daten basierenden Klassifikatoren zu invalidieren oder zu versionieren und als gelöscht zu markieren sind. Erforderliche Schritte bestehen im
Auffinden des zu wartenden Klassifikators, dessen Erweiterung, Aktualisierung oder Löschung
und Neuerzeugung sowie dessen Speicherung. Der Weg der Erweiterung, Aktualisierung oder
Neuerzeugung eines Klassifikators kann analog zu den zuvor beschriebenen Phasen stattfinden.
Der Ablauf der Wartung ist in Abbildung 4.7 dargestellt.
Im folgenden Abschnitt werden die identifizierten Komponenten näher betrachtet. Es werden
formal funktionale Operatoren für die einzelnen Phasen und Abläufe definiert und bezüglich
ihrer Signaturen beschrieben.
4.3. Beschreibung der Operatoren und Signaturen
Es wurden drei unterschiedliche Analyse-Abläufe im Kontext von ReKlaMe identifiziert:
1. die Induktion von Klassifikatoren auf verteilten Datenquellen (siehe Abbildungen 4.2
und 4.3)
2. die Anwendung von Klassifikatoren auf verteilten Datenquellen (siehe Abbildungen 4.4
und 4.6)
3. die Wartung induzierter Klassifikatoren (siehe Abbildung 4.2.2)
54
4.3 B ESCHREIBUNG DER O PERATOREN UND S IGNATUREN
55
Abbildung 4.7.: Wartung von Basisklassifikatoren: Invalidierung, Aktualisierung und Neugenerierung
Jeder dieser Abläufe basiert auf einer Menge von Operatoren, die in diesem Abschnitt genauer
beschrieben und deren Signaturen konzeptioniert werden sollen. Dazu werden in den folgenden
Abschnitten die Abläufe einzeln betrachtet. Für die nachfolgenden Abschnitte sei vorgegeben:
• MDSO die Metadatenmenge zur Selektion von Trainings- oder Instanzen-Daten,
• MBSO die Metadatenmenge zur Selektion eines Basisklassifikators,
• MIO die Metadatenmenge zur Parametrisierung des Induktions-Operators,
• MIIO die Metadatenmenge zur Parametrisierung des inkrementellen InduktionsOperators,
• MKO die Metadatenmenge zur Parametrisierung eines Klassifikations-Operators,
• MSGO die Metadatenmenge zur Parametrisierung des Operators zur Selection-GraphAbleitung,
• MM LO die Metadatenmenge zur Parametrisierung eines Meta-Lern-Operators,
• MIN O die Metadatenmenge zur Parametrisierung eines Invalidierungs-Operators und
• m ∈ {MDSO |MBSO |MIO |MIIO |MM LO |MIN O } ein Metadatum.
Weiter seien vorgegeben:
• T die Menge der Trainingsdatenmengen und t ∈ T eine Trainingsdatenmenge,
• C die Menge der Klassen von Datensätzen und z ∈ C eine Datensatz-Klasse,
• D die Menge der Instanzen-Datensätze und i ∈ D eine zu klassifizierende Instanz,
• ϕ die Menge der Basisklassifikatoren und k, k1 , k2 , . . . , kn ∈ ϕ Basisklassifikatoren,
• kinv ∈ ϕ ein invalidierter Basisklassifikator,
• kT ∈ ϕ ein Basisklassifikator erweitert durch die Trainingsdatenmenge T,
55
56
• Φ die Menge der globalen Klassifikatoren und kϕ ∈ Φ ein globaler Klassifikator, der von
einem Meta-Lerner auf Basis der Basisklassifikatoren k1 , k2 , . . . , kn ∈ ϕ erzeugt wurde,
• Q die Menge von Datenbankabfragen sowie
• S die Menge von Selection Graphs.
4.3.1. Operatoren für die Induktion eines Klassifikators auf verteilten
Datenquellen
Die in Abbildung 4.2 dargestellten Analyseabläufe der Induktion und Erweiterung von Klassifikatoren auf Basis verteilter Datenquellen sowie die Anwendung eines Meta-Lern-Prozesses,
wie in Abbildung 4.3 dargestellt, erfordern die Konzeption von mehreren Operatoren. Diese
seien im Folgenden vorgestellt.
Daten-Selektions-Operator DSO: Die Erzeugung der Basisklassifikatoren auf den verteilten Datenquellen basiert auf der Interpretation von Metadaten, die die Datenquellen
beschreiben und die Induktion von Basisklassifikatoren und globalen Modellen steuern.
So sind zur Induktion eines Klassifikators auf einer Datenquelle Metadaten über die zu
Grunde liegenden Instanzen, also beispielsweise über Tupel und Attribute einer Relation
in der Datenquelle, die als Eingabedatenmenge dienen sollen, vonnöten. Diese Informationen stehen einem Daten-Selektions-Operator zur Verfügung. Anhand der Metainformationen kann dieser die Tupel von Attributwerten aus der Datenquelle extrahieren, die
die für die Induktion interessanten Trainingsdaten darstellen, und diese einem nachfolgenden Operator zur weiteren Verarbeitung übergeben.
Bezüglich der Signatur des Daten-Selektions-Operators ist die Möglichkeit der Entgegennahme von Metadaten m ∈ MDSO zu berücksichtigen. Diese Metadaten müssen
Informationen beinhalten, die zur Extraktion der benötigten Daten und gegebenenfalls
zur Parametrisierung des nachfolgenden Operators vonnöten sind. Es muss weiterhin eine ausgehende Schnittstelle existieren, die eine Anfrage an die Datenquelle stellt, um die
erwünschten Instanzen zu selektieren. Eine zusätzliche eingehende Schnittstelle muss
die von der Datenquelle gelieferten Daten entgegennehmen können. Schließlich muss
die entgegengenommene Trainingsdatenmenge t ∈ T über eine ausgehende Schnittstelle
an einen nachfolgenden Operator weitergegeben werden können.
Die Signatur dieses Operators ist durch eine Abbildung
DSO : MDSO → T.
(4.1)
darstellbar.
Induktions-Operator (Lerner) IO: Der Induktions-Operator, im Folgenden auch Lerner
genannt, erzeugt auf Basis von Eingabedaten, den Trainingsdaten, einen Basisklassifikator. Die Trainingsdatenmenge besteht aus Instanzen i ∈ t, die ihrerseits aus Tupeln
von Attributwerten bestehen. Zusätzlich sind Metadaten notwendig, um das Lernverfahren parametrisieren zu können. Durch Anwendung eines Klassifikator-InduktionsVerfahrens erzeugt der Lerner dann einen Basisklassifikator und stellt ihn einer nachfolgenden Komponente zur Verfügung.
Die Signatur des Lerners muss zunächst eine Schnittstelle zur Annahme einer Menge von
Trainingsdaten t ∈ T vorsehen. Weiter muss eine Menge von Metadaten m ∈ MIO zur
Parametrisierung der Induktions-Algorithmen angenommen werden können. Die Ausgabe des Lerners sieht die Bereitstellung des erzeugten Basisklassifikators k ∈ ϕ in einer
entsprechenden Datenrepräsentation vor.
56
57
IO : T × MIO → ϕ.
(4.2)
darstellbar.
Basisklassifikator-Selektions-Operator BSO: In Abbildung 4.2b) ist ein inkrementeller Lerner dargestellt. Dieser benötigt neben neuen Trainingsdaten, die durch einen
Daten-Selektions-Operator DSO zur Verfügung gestellt werden, einen Basisklassifikator, der auf Basis der neuen Trainingsdaten erweitert wird. Der BasisklassifikatorSelektions-Operator BSO selektiert den zu erweiternden Basisklassifikator k aus einer
Menge von Klassifikatoren und stellt ihn einem nachfolgenden Operator, in diesem Falle
dem inkrementellen Lern-Operator IIO, zur Erweiterung zur Verfügung.
Die Signatur des BSO erfordert eine Schnittstelle für die Annahme einer Menge von
Metadaten m ∈ MBSO , die zur Selektion des gewünschten Basisklassifikators k aus
einer Menge von Basisklassifikatoren ϕ benötigt werden. Es müssen Schnittstellen zur
Selektion und zur Entgegennahme eines Basisklassifikators k ∈ ϕ umgesetzt werden.
Schließlich muss der selektierte Basisklassifikator k ∈ ϕ über eine ausgehende Schnittstelle an einen nachfolgenden Operator in einem entsprechenden Datenformat weitergegeben werden können.
BSO : MBSO → ϕ.
(4.3)
darstellbar.
Inkrementeller Lern-Operator IIO: Der Inkrementelle Lern-Operator kann einen Basisklassifikator anhand von zusätzlichen Trainingsdaten erweitern bzw. aktualisieren.
Dazu bedient er sich inkrementeller Lern-Methoden wie beispielsweise dem BOATAlgorithmus [GGRL99], die hier nicht weiter betrachtet werden.
Die Signatur dieses Operators sieht eine eingehende Schnittstelle für die Trainingsdatenmenge t ∈ T entsprechend der des Daten-Selektions-Operators DSO sowie für einen
Basisklassifikator k ∈ ϕ in einem entsprechenden Datenformat vor. Zudem muss eine
eingehende Schnittstelle für zusätzliche Metainformationen m ∈ MIIO existieren, anhand derer ein inkrementeller Lern-Algorithmus konfiguriert und parametrisiert werden
kann. Eine ausgehende Schnittstelle zur Übermittlung des erweiterten Basisklassifikators
kT ∈ ϕ an einen nachfolgenden Operator ist ebenfalls vorzusehen.
IIO : T × ϕ × MIIO → ϕ.
(4.4)
darstellbar.
Meta-Lern-Operator M LO: Der Meta-Lern-Operator erstellt anhand mehrerer Basisklassifikatoren ein globales Modell.
Die Signatur dieses Operators sieht eine eingehende Schnittstelle für mehrere Basisklassifikatoren k1 , k2 , . . . , kn ∈ ϕ vor. Weiterhin ist auch hier eine Schnittstelle zur
Annahme von Metainformationen MM LO vorzusehen, um den Meta-Lern-Algorithmus
parametrisieren zu können. Zur Ausgabe des globalen Modelles ist eine Schnittstelle
zu konzeptionieren, die nachfolgenden Operatoren das erzeugte Modell kϕ ∈ Φ zur
Verfügung stellen kann. Spezielle Meta-Lern-Methoden wie beispielsweise EnsembleLerner (siehe dazu [Pre05]) benötigen zusätzlich noch eine Menge von Trainingsdaten
t ∈ T, um ein globales Modell zu erzeugen.
57
58
M LO : ϕ × . . . × ϕ × MM LO → Φ.
(4.5)
M LO : ϕ × . . . × ϕ × MM LO × T → Φ.
(4.6)
bzw.
für Meta-Lern-Operatoren, die zusätzlich Trainingsdaten als Eingabe benötigen, darstellbar.
Basierend auf diesen Operatoren können die in den Abbildungen 4.2 und 4.3 abgebildeten
Abläufe bezüglich des Daten- und Kontrollflusses dargestellt werden. Eine Verbindung der
Operatoren untereinander und zum Gesamtsystem ist bisher jedoch noch nicht geschaffen. Dies
wird in Abschnitt 4.4.1 bzw. in Kapitel 5 geschehen.
4.3.2. Operatoren für die Anwendung eines Klassifikators auf verteilten
Datenquellen
Die Abläufe zur Anwendung eines Klassifikators auf verteilten Datenquellen im Kontext des
ReKlaMe-Szenarios sind in den Abbildungen 4.4 und 4.6 dargestellt. Die dazu notwendigen
Operatoren seien folgend vorgestellt.
Daten-Selektions-Operator DSO: Der Daten-Selektions-Operator selektiert die Instanzen aus der Datenquelle, die klassifiziert werden sollen. Dazu bedient er sich Metainformationen, anhand derer er die Attribute und Attributwerte identifizieren und selektieren
kann, die für die Durchführung der Klassifikation von Interesse sind.
Die Signatur des Selektions-Operators ist der Signatur des Daten-Selektions-Operators
DSO ähnlich, der in Abschnitt 4.3.1 ausführlich beschrieben wurde. So werden Metadaten m ∈ MDSO benötigt, anhand derer die zu klassifizierenden Instanzen i ∈ D
aus der Datenquelle selektiert werden können. Der Unterschied besteht darin, dass die
aus der Datenquelle selektierten Daten in diesem Fall nicht Trainingsdaten, sondern zu
klassifizierende Instanzen sind. Eine eingehende Schnittstelle zur Entgegennahme von
Metadaten m ∈ MDSO ist dazu erforderlich. Zudem erfordert die Funktionalität dieses Operators eine eingehende Schnittstelle für die selektierten Instanzen i ∈ D aus
der Datenquelle. Eine ausgehende Schnittstelle für die selektierten Daten D ist ebenfalls
vonnöten, um diese an einen nachfolgenden Operator weiterreichen zu können.
DSO : MDSO → D.
(4.7)
darstellbar.
Klassifikations-Operator KO: Der Klassifikations-Operator nimmt Instanzen der zu klassifizierenden Daten entgegen. Ein Algorithmus zur Anwendung des Klassifikators teilt
diese Instanzen in eine durch den Klassifikator bestimmte Anzahl von Zielmengen auf.
Die Signatur des Klassifikations-Operators erfordert eine eingehende Schnittstelle zur
Annahme der zu klassifizierenden Instanzen D und der dazu notwendigen Metadaten
m ∈ MKO . Eine ausgehende Schnittstelle muss die erzeugten Zielklassen z ∈ C an
einen weiteren Operator übergeben können, der diese weiterverarbeitet.
KO : MKO × D × ϕ → C.
darstellbar.
58
(4.8)
59
Operator zur Selection-Graph-Ableitung SGO: Der Operator zur Selection-GraphAbleitung erzeugt auf Basis eines Klassifikators eine Menge von Selection Graphs (SG).
Für jeden Weg durch den Baum zu einem Blatt (also zu einer Zielklasse) wird ein SG
erzeugt. Auf die genaue Erzeugung eines Selection Graphs soll hier nicht weiter eingegangen werden. Dazu sei auf [Saa04] verwiesen.
Die Signatur dieses Operators erfordert eine eingehende Schnittstelle für Metadaten m ∈
MSGO zur Parametrisierung des Operators zur Selection-Graph-Ableitung sowie eine
eingehende Schnittstelle für den anzuwendenden Klassifikator k ∈ ϕ. Eine ausgehende
Schnittstelle für die erzeugten SG S ist ebenfalls vorzusehen.
SGO : MSGO × ϕ → S.
(4.9)
darstellbar.
Basisklassifikator-Selektions-Operator BSO: Um aus einem Klassifikator eine Menge von Selection Graphs ableiten zu können, muss der Klassifikator dem SGO zur
Verfügung stehen. Dazu wird ein Basisklassifikator-Selektions-Operator BSO benötigt,
der sich analog zu dem in Abschnitt 4.3.2 beschriebenen BSO verhält.
Die Signatur des Basisklassifikator-Selektions-Operators erfordert demnach ebenfalls eine Schnittstelle für die Annahme einer Menge von Metadaten m ∈ MBSO , die zur Selektion des gewünschten Basisklassifikators k aus einer Menge von Basisklassifikatoren
ϕ benötigt werden. Es müssen Schnittstellen zur Selektion und zur Entgegennahme eines
Basisklassifikators k ∈ ϕ umgesetzt werden. Schließlich muss der selektierte Basisklassifikator k ∈ ϕ über eine ausgehende Schnittstelle an einen nachfolgenden Operator in
einem entsprechenden Datenformat weitergegeben werden können.
BSO : MBSO → ϕ.
(4.10)
darstellbar.
Selection Graph-Transformations-Operator SGT O: Dieser Operator transformiert die
vom Operator zur Selection-Graph-Ableitung erzeugten SG in ein Format zur Abfrage
der relationalen Datenbank, die diesem Ansatz zu Grunde liegen muss. Anhand der erzeugten Datenbankabfragen können die Instanzen der verteilten Datenquellen nun durch
Anwendung der Anfrage an die Datenbank von der Datenbanklogik selektiert und ausgegeben werden.
Bezüglich der Signatur dieses Operators sind eine eingehende Schnittstelle zur Entgegennahme der SG S sowie eine ausgehende Schnittstelle zur Weitergabe der erzeugten
Abfragemenge Q an die relationalen Datenbanken vorzusehen.
SGT O : S → Q.
(4.11)
darstellbar.
Wrapping-Operator zur relationalen Datenbank W O: Ein Operator zum Wrapping
der Datenbank-Funktionalität ist erforderlich, um Datenbankabfragen auf einer Datenquelle ausführen und die Ergebnisse einem nachfolgenden Operator zur Verfügung stellen zu können.
Die Signatur des Wrappers erfordert eine eingehende Schnittstelle für die Datenbankabfragen Q, die an die relationale Datenbank weitergegeben werden. Eine ausgehende
59
60
Schnittstelle mit den Ergebnissen der Datenbankabfragen, den Klassen von Instanzen
z ∈ C ist ebenfalls vorzusehen, und gegebenenfalls sind weitere Metadaten bezüglich
der Ergebnisse über eine zusätzliche ausgehende Schnittstelle bereitzustellen.
W O : Q → C.
(4.12)
darstellbar.
Die in diesem Abschnitt vorgestellten Operatoren erlauben die Umsetzung der in den Abbildungen 4.4 und 4.6 dargestellten Vorgänge zur Anwendung von Klassifikatoren auf verteilten
Datenquellen. Auch hier wird die Verbindung der Operatoren untereinander im Detail erst in
Abschnitt 4.4.2 durchgeführt.
4.3.3. Operatoren für die Wartung von Klassifikatoren
Die Abläufe, die zum Prozess des Wartens von Klassifikatoren identifiziert wurden, sind in Abbildung 4.2.2 aufgezeigt. Im Ablauf der Wartung sind zwei unterschiedliche Phasen zu identifizieren: die Neugenerierung und die Erweiterung von vorhandenen Basisklassifikatoren. Die
für diese Phasen erforderlichen Operatoren werden im Folgenden näher betrachtet.
Basisklassifikator-Selektions-Operator BSO: Für beide Phasen der Wartung ist
zunächst der zu wartende Basisklassifikator aus der Menge der Basisklassifikatoren
zu selektieren. Dazu bedarf es eines Operators, der mit dem in Abschnitt 4.3.1 beschriebenen Basisklassifikator-Selektions-Operator aus dem Induktions-Ablauf zu vergleichen
ist.
Die Signatur dieses Operators erfordert demnach eine Schnittstelle für die Annahme von
Metainformationen MBSO , die zur Selektion des gewünschten Basisklassifikators k aus
einer Menge von Basisklassifikatoren ϕ benötigt werden. Auch hier müssen Schnittstellen zur Selektion und zur Entgegennahme eines Basisklassifikators umgesetzt werden.
Schließlich muss der selektierte Basisklassifikator k ∈ ϕ ebenfalls über eine ausgehende Schnittstelle an einen nachfolgenden Operator in einem entsprechenden Datenformat
weitergegeben werden können.
BSO : MBSO → ϕ.
(4.13)
darstellbar.
Meta-Lern-Operator M LO: Der Meta-Lern-Operator entspricht dem in Abschnitt 4.3.1
beschriebenen Meta-Lern-Operator. Er generiert ein globales Modell unter Verwendung
mehrerer Basisklassifikatoren.
Die Signatur dieses Operators sieht analog zu dem in Abschnitt 4.3.1 beschriebenen Operator eine eingehende Schnittstelle für Basisklassifikatoren k ∈ ϕ und eine zur Annahme
von Metainformationen m ∈ MM LO vor, um den Meta-Lern-Algorithmus parametrisieren zu können. Zur Ausgabe des globalen Modelles kϕ ∈ Φ ist eine Schnittstelle zu konzeptionieren, die nachfolgenden Operatoren das erzeugte Modell kϕ ∈ Φ zur Verfügung
stellen kann. Auch hier können Meta-Lern-Verfahren wie z.B. Ensemble-Lerner zum
Einsatz kommen, die zusätzlich die Eingabe einer Trainingsdatenmenge t ∈ T benötigen.
60
61
M LO : ϕ × . . . × ϕ × MM LO → Φ.
(4.14)
M LO : ϕ × . . . × ϕ × MM LO × T → Φ.
(4.15)
bzw.
für Meta-Lern-Operatoren, die zusätzlich Trainingsdaten als Eingabe benötigen, darstellbar.
Invalidierungs-Operator IN O: Der Invalidierungs-Operator extrahiert zunächst Metainformationen aus dem eingehenden Klassifikator. Bei Umsetzung einer temporalen Versionierung kann der Operator dann den Klassifikator mit einem Zeitstempel versehen
und somit seine Invalidierung ausführen.
Im Hinblick auf die Signatur dieses Operators lassen sich zwei eingehende und zwei ausgehende Schnittstellen identifizieren. Ein Basisklassifikator k ∈ ϕ und eine Menge von
Metadaten m ∈ MIN O müssen vom Invalidierungs-Operator eingelesen werden. Der
zeitgestempelte, invalidierte Klassifikator kinv und die extrahierten und eingegebenen
Metadaten m ∈ M müssen an nachfolgende Operatoren weitergegeben werden können.
IN O : MIN O × ϕ → M × ϕ.
(4.16)
darstellbar.
Induktions-Operator (Lerner) IO: Der Induktions-Operator (Lerner) induziert analog zu
dem in Abschnitt 4.3.1 beschriebenen Lerner einen Basisklassifikator auf Basis von Metadaten und Trainingsdaten, den Instanzen. Anhand der eingegebenen Metadaten fordert
er die erwünschten Instanzen an und erzeugt durch Anwendung von Lern-Algorithmen
einen Basisklassifikator.
Die Signatur dieses Operators sieht eine eingehende Schnittstelle für Metadaten m ∈
MIO sowie eine eingehende Schnittstelle für angeforderte Trainingsdaten t ∈ T vor.
Über eine Ausgabeschnittstelle gibt der Operator den erzeugten Basisklassifikator k ∈ ϕ
an nachfolgende Operatoren weiter. Zusätzlich muss eine ausgehende Schnittstelle zu
einem Operator geschaffen werden, über die Metadaten m ∈ MIO zur Parametrisierung
des IO übergeben werden können.
IO : T × MIO → ϕ.
(4.17)
darstellbar.
Inkrementeller Lern-Operator IIO: Der Inkrementelle Lern-Operator kann analog zu
dem in 4.3.1 beschriebenen inkrementellen Lerner einen Basisklassifikator anhand von
zusätzlichen Trainingsdaten erweitern bzw. aktualisieren. Dazu bedient er sich ebenfalls
inkrementeller Lern-Methoden wie beispielsweise dem BOAT-Algorithmus [GGRL99],
die hier nicht weiter betrachtet werden.
Die Signatur dieses Operators sieht eine eingehende Schnittstelle für die Trainingsdatenmenge t ∈ T entsprechend der des Daten-Selektions-Operators DSO sowie für einen
Basisklassifikator k ∈ ϕ in einem entsprechenden Datenformat vor. Zudem muss eine
eingehende Schnittstelle für zusätzliche Metainformationen m ∈ MIIO existieren, anhand derer ein inkrementeller Lern-Algorithmus konfiguriert und parametrisiert werden
kann. Eine ausgehende Schnittstelle zur Übermittlung des erweiterten Basisklassifikators
kT ∈ ϕ an einen nachfolgenden Operator ist ebenfalls vorzusehen.
61
62
IIO : T × ϕ × MIIO → ϕ.
(4.18)
darstellbar.
Daten-Selektions-Operator DSO: Der Daten-Selektions-Operator extrahiert analog zu
dem Selektions-Operator aus Abschnitt 4.3.1 auf Basis von eingehenden Metadaten eine Menge von Tupeln, die Trainingsdaten, aus einer Datenquelle. Diese gibt er an den
anfragenden Operator zurück.
Die Signatur dieses Operators umfasst eine eingehende Schnittstelle für die Metadaten
m ∈ MDSO und eine ausgehende Schnittstelle für die selektierten Trainingsdaten t ∈ T.
DSO : MDSO → T.
(4.19)
darstellbar.
Die in diesem Abschnitt vorgestellten Operatoren erlauben die Umsetzung der in der Abbildung 4.2.2 dargestellten Vorgänge zur Wartung von Klassifikatoren im ReKlaMe-Kontext.
Analog zu den Abschnitten 4.3.1 und 4.3.2 wird die Verbindung der Operatoren untereinander ebenfalls nicht hier, sondern erst in Kapitel 4.4.3 im Detail durchgeführt.
4.4. Operationalisierte Beschreibung der einzelnen Abläufe
und Phasen
In diesem Abschnitt werden die in Abschnitt 4.2 beschriebenen Abläufe und Phasen unter
Berücksichtigung der Verbindungen der in Abschnitt 4.3 beschriebenen Operatoren untereinander aufgezeigt. Dazu werden die Abläufe der Reihe nach betrachtet und die identifizierten
Operatoren untereinander in Beziehung gesetzt.
4.4.1. Operationalisierte Beschreibung der Klassifikator-Induktion
Zunächst sei der Ablauf der einfachen Klassifikator-Induktion auf verteilten Datenquellen
betrachtet. Abbildung 4.8 zeigt den Ablauf unter Berücksichtigung der Operatoren, Datenund Metadatenflüsse. Anschließend wird die inkrementelle Klassifikator-Induktion erläutert.
Schließlich befasst dieser Abschnitt sich mit dem Erzeugen eines globalen Klassifikators durch
einen Meta-Lerner.
Induktion eines Klassifikators
Der Ablauf sei im Folgenden anhand einer Datenquelle beschrieben. Die Abläufe bezüglich der
anderen Datenquellen verlaufen analog. Nach Anstoßen der Klassifikator-Induktion werden die
Metadaten, auf Grundlage derer die Induktion durchgeführt werden soll, an den InduktionsOperator an der Datenquelle übergeben. Diese Metadaten dienen der Parametrisierung der
Induktions-Algorithmen. Weiter werden Metadaten an den Daten-Selektions-Operator übergeben, der die entsprechenden Instanzen der Trainingsdaten aus der Datenquelle selektiert und
an den Induktions-Operator zurückgibt. Der auf Basis dieser Trainingsdaten induzierte Basisklassifikator wird schließlich der Menge aller Basisklassifikatoren hinzugefügt.
62
4.4 O PERATIONALISIERTE B ESCHREIBUNG DER
EINZELNEN
A BL ÄUFE UND P HASEN
63
Abbildung 4.8.: Ablauf einer einfachen Klassifikator-Induktion
Auf Basis der in Abschnitt 4.3.1 formalisierten Abläufe an den einzelnen Operatoren lässt sich
der Ablauf der einfachen Induktion eines Basisklassifikators, im Folgenden als IN D bezeichnet, wie folgt formalisieren:
IN D
:
DSO ◦ IO
= (MDSO → T) ◦ (T × MIO → ϕ)
= MDSO × MIO → ϕ
(4.20)
Die Verknüpfung ◦ einer Abbildung f ◦ g sei aufgrund der strikt sequentiellen Ausführung
der Operatoren DSO und IO hier als einfache Nacheinanderausführung der Abbildungen f
und g definiert. Dabei werden die Ausgaben der Abbildung f als Eingaben der Abbildung g
vorgesehen. Sollten die Signaturen der Ausgabe von f mit denen der Eingabe von g nicht übereinstimmen, so werden die zusätzlich benötigten Eingaben für g den Eingaben der Abbildung
f ◦ g hinzugefügt. Diese Definition gelte auch für die folgenden Formalisierungen.
Somit ist die Abbildung IN D eine Abbildung aus der Menge der Metadatenmengen zur Steuerung des BSO und der Menge der Metadatenmengen zur Parametrisierung des IO in die Menge der Basisklassifikatoren.
Inkrementelle Induktion eines Klassifikators
In Abbildung 4.9 ist der Ablauf der inkrementellen Klassifikator-Induktion unter Berücksichtigung der Operatoren, Daten- und Metadatenflüsse aufgeführt. Ein Benutzer initiiert die inkrementelle Induktion durch Übergabe mehrerer Metadatenmengen an verschiedene Operatoren. Zunächst werden Metadaten an den DSO und den BSO übergeben. Diese selektieren
entsprechend der Metadaten die angeforderten Trainingsdaten bzw. den angeforderten Basisklassifikator. Die Trainingsdatenmenge und der Basisklassifikator werden an den IIO, den
inkrementellen Induktions-Operator übergeben. Anhand von zusätzlichen Metadaten zur Parametrisierung des inkrementellen Lern-Algorithmus wird nun der Basisklassifikator auf Basis
der Trainingsdaten erweitert und der Menge aller Basisklassifikatoren hinzugefügt.
63
64
Abbildung 4.9.: Ablauf einer inkrementellen Klassifikator-Induktion
Eine Formalisierung des Ablaufes der Inkrementellen Induktion, die im Folgenden mit IIN D
bezeichnet wird, lautet:
IIN D
:
(DSO|BSO) ◦ IIO
DSO
BSO
IIO
z
}|
{ z
}|
{
z
}|
{
= ((MDSO → T)|(MBSO → ϕ)) ◦ (T × ϕ × MIIO → ϕ)
= MDSO × MBSO × MIIO → ϕ.
(4.21)
Der Operator f |g sei in diesem Zusammenhang als Parallelausführung zweier Abbildungen f
und g definiert. Insbesondere gilt für die Abbildung (f |g) ◦ h, dass die Bilder der Abbildungen
f und g als Urbild der Abbildung h fungieren.
Die Abbildung IIN D ist also eine Abbildung aus der Menge der Metadatenmengen zur Steuerung des DSO und der Menge der Metadatenmengen zur Steuerung des BSO und der Menge
der Metadatenmengen zur Parametrisierung des IO in die Menge der Basisklassifikatoren.
Erzeugen eines globalen Klassifikators durch einen Meta-Lerner
Abbildung 4.10 zeigt den Ablauf der Induktions-Phase des Meta-Lernens. Ein Benutzer sendet die Metadaten, die zur Analyse notwendig sind, an die Basisklassifikator-SelektionsOperatoren der verteilten Datenquellen. Die angeforderten Basisklassifikatoren werden anschließend an den Meta-Lern-Operator weitergeleitet. Eine sequentielle Wiederholung der Anforderung verschiedener Basisklassifikatoren aus einer Quelle ist ebenfalls umsetzbar. In diesem Fall muss der Meta-Lern-Operator auf die Eingabe von Metadaten durch den Benutzer
warten, die dem Meta-Lern-Operator genaue Informationen über die Eingabedaten liefern. Der
Meta-Lern-Operator erzeugt aus den eingegangenen Basisklassifikatoren entsprechend der Metadaten, die ihm vom Benutzer übermittelt wurden, einen globalen Klassifikator, der der Menge
aller globalen Klassifikatoren hinzugefügt wird.
64
EINZELNEN
65
Abbildung 4.10.: Ablauf des Meta-Lernens
Die Formalisierung des Ablaufes des Meta-Lernens, im Folgenden mit M L bezeichnet, sei nun
gegeben durch:
Datenquelle 1
ML
:
Datenquelle n
}|
{
z
}|
{
z
((BSO ◦ · · · ◦ BSO)| · · · |(BSO ◦ · · · ◦ BSO)) ◦ M LO
Datenquelle 1
Datenquelle n
}|
{
}|
{
z
z
= ((MBSO → ϕ) ◦ · · · ◦ (MBSO → ϕ)| · · · |((MBSO → ϕ) ◦ · · · ◦ (MBSO → ϕ)) ×
M LO
z
}|
{
(ϕ × · · · × ϕ × MM LO → Φ)
= (MBSO × · · · × MBSO ) × MM LO → Φ
(4.22)
bzw.
Datenquelle 1
ML
:
Datenquelle n
Datenq. 1
Datenq. n
z
}|
{
z
}|
{
z }| {
z }| {
((BSO ◦ · · · ◦ BSO)| · · · |(BSO ◦ · · · ◦ BSO)) ◦ ( DSO | · · · | DSO ) ◦ M LO
Datenquelle 1
Datenquelle n
z
}|
{
z
}|
{
= ((MBSO → ϕ) ◦ · · · ◦ (MBSO → ϕ)| · · · |((MBSO → ϕ) ◦ · · · ◦ (MBSO → ϕ)) ×
Datenquelle 1
Datenquelle n
M LO
z
}|
{
z
}|
{
z
}|
{
((MDSO → T)| · · · |(MDSO → T)) × (ϕ × · · · × ϕ × MM LO → Φ)
= (MBSO × · · · × MBSO ) × (MDSO × · · · × MDSO ) × MM LO → Φ
(4.23)
Insgesamt lässt sich der Ablauf des Meta-Lernens als eine Abbildung aus dem Kreuzprodukt
der Mengen der Metadatenmengen zur Steuerung der BSO und der Menge der Metadatenmengen zur Steuerung des Meta-Lerners in die Menge der globalen Klassifikatoren darstellen. Im
Falle eines Meta-Lern-Verfahrens, welches zusätzlich auf der Eingabe von Trainingsdaten beruht, muss die Abbildung auf Seiten der Urbilder zusätzlich um das Kreuzprodukt der Mengen
der Metadatenmengen zur Steuerung der DSO erweitert werden.
65
66
Alle in Abschnitt 4.3.1 aufgeführten Phasen des Induktions-Analyse-Ablaufes sind somit
bezüglich der zugrunde liegenden Operatoren beschrieben. Für die einzelnen Abläufe wurden
Formalisierungen gefunden und sie wurden in Form von Abbildungen beschrieben.
4.4.2. Operationalisierte Beschreibung der Klassifikator-Anwendung
In diesem Abschnitt wird zunächst der naive Ansatz der Anwendung eines Klassifikators zur
Klassifikation von Daten einer Datenquelle betrachtet, bei dem der Entscheidungsbaum auf
jede zu klassifizierende Instanz der Datenmenge angewendet wird. Die zum Ablauf dieser
ReKlaMe-Analyse benötigten Operatoren und deren Signaturen wurden bereits in Abschnitt
4.3.2 aufgeführt. Anschließend wird ein alternativer Ansatz der Klassifikation durch Erzeugen
von Selection-Graphs aus Klassifikatoren, Transformation der Selection Graphs in DatenbankAbfragen und Anwendung dieser Abfragen auf verteilten relationalen Datenquellen dargestellt.
Dieser Ansatz stellt eine performantere Alternative zum naiven Ansatz dar.
Naiver Klassifikations-Ansatz
Abbildung 4.11 stellt die Verbindungen der Operatoren zur naiven Klassifikator-Anwendung
dar.
Abbildung 4.11.: Ablauf einer Klassifikator-Anwendung
Wird die Klassifikation von einem Benutzer initiiert, so werden Metadaten zur Selektion des
anzuwendenden Klassifikators, Metadaten zur Selektion der zu klassifizierenden Instanzen sowie Metadaten zur Parametrisierung des Klassifikations-Operators an die jeweiligen Operatoren übergeben. Der DSO führt die Selektion der Instanzen, der BSO die Selektion des Klassifikators aus, und der KO kann auf Basis der Instanzen und des Klassifikators sowie der Metadaten zur Parametrisierung die Klassifikation durchführen. Jede Instanz wird entsprechend der
Anwendung des Klassifikators einer Zielklasse zugewiesen und in den Klassifikationsergebnissen gesammelt. Diese können über eine Ausgabeschnittstelle einem weiterverarbeitenden
Operator zur Verfügung gestellt werden.
66
EINZELNEN
Formal kann die Durchführung einer solchen Klassifikation durch die Abbildung
Datenquelle 1
KLA
Datenquelle n
:
z
z
}|
{
}|
{
((DSO|BSO) ◦ KO)| · · · |((DSO|BSO) ◦ KO)
=
z
}|
{
(((MDSO → D)|(MBSO M → ϕ)) ◦ (MKO × D × ϕ → C))| · · · |
Datenquelle 1
Datenquelle n
z
}|
{ (((MDSO → D)|(MBSO → ϕ)) ◦ (MKO × D × ϕ → C))
Datenq. 1
Datenq. n
Datenq. n
Datenq. 1
z }| {
z }| {
z }| {
z }| {
= (MDSO × · · · × MDSO ) × (MBSO × · · · × MBSO ) × MKO → C (4.24)
|
|
{z
}
{z
}
Instanzenselektion
Klassifikatorselektion
dargestellt werden.
Dieser Ablauf lässt sich also als Abbildung des Kreuzproduktes der Mengen der Metadatenmengen zur Instanzenselektion, der Mengen der Metadatenmengen zur Instanzenselektion sowie der Menge der Metadatenmengen zur Klassifikator-Parametrisierung in die Menge der
Zielklassenmengen darstellen.
Klassifikation durch Selection-Graph-Ableitung
Die Klassifikation durch Ableitung von Selection Graphs aus Klassifikatoren und Wandlung der Selection Graphs in relationale Datenbankabfragen wurde bereits in Abschnitt 4.3.2
bezüglich der Operatoren beschrieben. Nun folgt die Beschreibung des Zusammenspieles dieser Operatoren, welches in Abbildung 4.12 dargestellt ist. Ein Benutzer initiiert die Klassifikation, indem er Metadaten an den SGO und an einen BSO sendet. Durch die an den BSO
gesendeten Metadaten wird die Klassifikator-Extraktion initiiert. Der SGO nimmt den selektierten Klassifikator entgegen und wandelt ihn in eine Menge von Selection Graphs. Die Selection Graphs werden an den SGT O weitergegeben, der sie zu Datenbank-Abfragen konvertiert.
Diese Abfragen werden den W O der verteilten Datenquellen übergeben, die die Anfragen auf
den relationalen Datenquellen ausführen. Jede Abfrage selektiert die Instanzen einer Zielklasse.
Abbildung 4.12.: Ablauf einer verteilten Klassifikation durch Ableitung von Selection Graphs
und deren Wandlung in Datenbankabfragen
Der Ablauf der Klassifikation durch Ableitung von Selection Graphs lässt sich formal durch
67
67
68
folgende Abbildung SGK beschreiben:
SGK
:
BSO ◦ SGO ◦ SGT O ◦ (W O| · · · |W O)
BSO
SGO
SGTO
WO Datenq. 1
WO Datenq. n
z
z
z }| {
}|
{
}|
{
z }| {
z }| {
= (MBSO → ϕ) ◦ (MSGO × ϕ → S) ◦ (S → Q) ◦ (( Q → C )| · · · |( Q → C ))
= MBSO × MSGO → C
(4.25)
Der Ablauf dieser Klassifikationsmethode lässt sich also durch eine Abbildung aus dem Kreuzprodukt der Mengen der Metadatenmengen zur Selektion eines Klassifikators und der Menge
der Metadatenmengen zur Parametrisierung des SGO in die Menge der Zielklassenmengen
darstellen.
Somit sind die Phasen des Anwendungs-Ablaufes einer ReKlaMe-Analyse, die in Abschnitt
4.3.2 beschrieben sind, ebenfalls darstellbar.
4.4.3. Operationalisierte Beschreibung der Klassifikator-Wartung
In diesem Abschnitt werden die verschiedenen Phasen und Abläufe der Wartung von Klassifikatoren operational formal beschrieben. Zunächst wird die gegebenenfalls inkrementelle
Aktualisierung oder Neugenerierung eines Klassifikators betrachtet. Anschließend erfolgt die
Betrachtung der Erweiterung von Klassifikatoren durch Meta-Lerner (beispielsweise Kombinierer).
(Inkrementelle) Aktualisierung und Neugenerierung von Klassifikatoren
Abbildung 4.13.: Phase der (inkrementellen) Aktualisierung/Neugenerierung eines Klassifikators im Ablauf der Wartung
Der Ablauf der (inkrementellen) Aktualisierung bzw. Neugenerierung eines Basisklassifikators
ist in Abbildung 4.13 dargestellt. Anhand von Metadaten wird der zu aktualisierende Klassifikator über einen BSO selektiert und dem IN O übergeben. Dieser markiert die Löschung
des Klassifikators in der Menge aller Basisklassifikatoren anhand von Zeitstempeln. Metadaten werden anschließend an einen weiteren BSO übergeben, der den zu aktualisierenden oder
68
EINZELNEN
69
neu zu generierenden Klassifikator selektieren und dem IIO übergeben kann. Dieser fordert
anhand der ihm übergebenen Metadaten die benötigten Trainingsdaten aus einer Datenquelle
mittels eines DSO an. Auf Basis der Trainings- und Metadaten kann ein neuer oder aktualisierter Klassifikator induziert werden. Dieser wird der Menge aller Klassifikatoren hinzugefügt.
Formal kann der Ablauf der Aktualisierung bzw. Neugenerierung eines Klassifikators als eine
Abbildung AN K:
AN K
:
BSO ◦ IN O ◦ (BSO ◦ · · · ◦ BSO) ◦ DSO ◦ IIO
BSO
INO
z
}|
{
}|
{
z
= (MBSO → ϕ) ◦ (MIN O × ϕ → M × ϕ) ◦
BSO
BSO
DSO
IIO
z
}|
{
}|
{
}|
{
}|
{
z
z
z
((MBSO → ϕ) ◦ · · · ◦ (MBSO → ϕ)) ◦ (MDSO → T) ◦ (T × ϕ × MIIO → ϕ)
= MBSO × MIN O × (MBSO × · · · × MBSO ) × MDSO × MIIO → ϕ × ϕ (4.26)
definiert werden.
Die Abbildung AN K lässt sich also als eine Abbildung aus dem Kreuzprodukt der Menge der
Metadatenmengen zur Basisklassifikatorselektion, der Menge der Metadatenmengen zur Parametrisierung des IN O, der Menge der Metadatenmengen zur Selektion der dem IIO zugrunde
liegenden Klassifikatoren, der Menge der Metadatenmengen zur Selektion der Trainingsdaten
und der Menge der Metadatenmengen zur Parametrisierung des IIO in das Kreuzprodukt der
Menge der invalidierten Basisklassifikatorenmengen und der Menge der Basisklassifikatorenmengen darstellen.
Erweiterung von Klassifikatoren durch Meta-Lerner
Abbildung 4.14.: Phase der Erweiterung eines Klassifikators durch einen Meta-Lerner im Ablauf der Wartung
Abbildung 4.14 zeigt den Ablauf der Erweiterung eines Klassifikators durch einen MetaLerner. Über Metadaten wird die Selektion des zu erweiternden Basisklassifikators von einem
69
70
BSO durchgeführt. Dieser wird dem IN O übergeben, der anhand zusätzlicher Metadaten eine Invalidierung durch Zeitstempelung durchführt. Der invalidierte Basisklassifikator wird der
Menge aller Basisklassifikatoren zugeführt. Anhand von durch den IN O erzeugten Metadaten über den zu erweiternden Klassifikator wird dieser über einen weiteren BSO selektiert
und einem M LO zugeführt. Anhand von zusätzlichen Metadaten zur weiteren Klassifikatorselektion können zusätzlich noch die Klassifikatoren selektiert werden, die für die Erweiterung
genutzt werden sollen. Der Meta-Lerner kann anhand des zu erweiternden Klassifikators, der
Klassifikatoren, die für die Erweiterung genutzt werden sollen sowie anhand von parametrisierenden Metadaten nun ein globales Modell erzeugen. Dieses wird ebenfalls der Menge aller
Basisklassifikatoren zugeführt.
Formal lässt sich die Erweiterung eines Klassifikators als eine Abbildung KE
:
KE
BSO ◦ IN O ◦ BSO ◦ (BSO ◦ · · · ◦ BSO) ◦ M LO
IN O
BSO
BSO
z
z
}|
{
}|
{
}|
{
z
= (MBSO → ϕ) ◦ (MIN O × ϕ → M × ϕ) ◦ (MBSO → ϕ) ◦
BSO 1
BSO n
MLO
}|
{
}|
{
z
z }| {
z
((MBSO → ϕ) ◦ · · · ◦ (MBSO × ϕ)) ◦ (ϕ × · · · × ϕ × MM LO → Φ)
= MBSO × MIN O × (MBSO × · · · × MBSO ) × MM LO → ϕ × Φ
(4.27)
bzw.
KE
:
BSO ◦ IN O ◦ BSO ◦ (BSO ◦ · · · ◦ BSO) ◦ M LO
IN O
BSO
BSO
z
z
}|
{
}|
{
}|
{
z
= (MBSO → ϕ) ◦ (MIN O × ϕ → M × ϕ) ◦ (MBSO → ϕ) ◦
BSO 1
BSO n
MLO
z
}|
{
z }| {
z
}|
{
((MBSO → ϕ) ◦ · · · ◦ (MBSO × ϕ)) ◦ (ϕ × · · · × ϕ × MM LO × T → Φ)
= MBSO × MIN O × (MBSO × · · · × MBSO ) × MM LO × T → ϕ × Φ
(4.28)
für MLO, die zusätzlich Trainingsdaten benötigen, darstellen.
Der Ablauf der Klassifikator-Erweiterung ist also eine Abbildung aus dem Kreuzprodukt der
Menge der Metadatenmengen zur Selektion des zu erweiternden Klassifikators, der Menge der
Metadatenmengen zur Parametrisierung des IN O, der Menge der Metadatenmengen zur Selektion der Klassifikatoren, die der Erweiterung des zu erweiternden Klassifikators zugrunde
liegen sowie der Menge der Metadatenmengen zur Parametrisierung des M LO und gegebenenfalls der Menge der Trainingsdatenmengen für den zu erweiternden Klassifikator in das Kreuzprodukt der Menge der invalidierten Basisklassifikatorenmengen und der Menge der globalen
Klassifikatormengen.
Durch diese Abläufe können die Phasen des Wartungs-Ablaufes einer ReKlaMe-Analyse, die
in Abschnitt 4.3.3 beschrieben sind, auch dargestellt werden.
Insgesamt wurden die Abläufe und Phasen, die im Rahmen des ReKlaMe-Ansatzes identifiziert wurden, durch Operatoren und deren Verbindungen untereinander beschrieben und formal
durch Abbildungen spezifiziert. Das Ausführungsmodell beinhaltet alle formal spezifizierten
Abläufe und Phasen und wird durch sie definiert. Im folgenden Kapitel wird die Ableitung einer
Architektur aus dem Ausführungsmodell durchgeführt. Dabei werden Komponenten definiert,
Daten- und Kontrollflüsse spezifiziert und Datenformate konzeptioniert. Auch Schnittstellen
werden konkret spezifiziert.
70
71
In diesem Kapitel wurden in Abschnitt 4.1 die Zielsetzungen des ReKlaMe-Projektes ausführlich beleuchtet, um auf dieser Basis ein Ausführungsmodell für die im Rahmen des ReKlaMeProjektes zu ermöglichenden Analysen zu konzeptionieren. Dazu wurde zunächst ein Überblick über die Ziele des Ansatzes, die zugrunde liegende Umgebung sowie die Rahmenbedingungen geschaffen, die das Projekt umschließen. Anschließend wurden in Abschnitt 4.2
verschiedene Abläufe und Phasen der Analyseschritte identifiziert. Zu den drei identifizierten
Abläufen zählen die Induktion von Klassifikatoren auf Basis verteilter Datenquellen, die Anwendung dieser auf verteilten Datenquellen sowie die Wartung, und darin eingeschlossen, die
Aktualisierung der induzierten Klassifikatoren.
Folgend wurden in Abschnitt 4.3 die drei Abläufe ausführlich betrachtet und für jede Art von
Ablauf im Rahmen des ReKlaMe-Projektes Kontroll- und Datenflüsse sowie Funktionalität
in Form von Operatoren zur Umsetzung der Abläufe konzeptioniert. Anschließend erfolgte
eine ausführliche Betrachtung dieser Operatoren bezüglich ihrer Signaturen. So wurde jeder
Operator durch eine Abbildung formalisiert.
Auf Basis dieser Formalisierungen konnte dann in Abschnitt 4.4 eine operationalisierte Beschreibung der identifizierten Abläufe durchgeführt werden. Diesbezüglich wurde jeder Ablauf
durch eine formale Abbildung beschrieben, die aus der Verknüpfung von Nacheinander- oder
Parallelausführung der Abbildungen besteht, die die am jeweiligen Ablauf beteiligten Operatoren beschreiben.
Schließlich ließ sich das Ausführungsmodell durch die identifizierten Abläufe und die formalisierten Beschreibungen der einzelnen Abläufe spezifizieren.
71
72
72
5. Architekturentwurf
Im vorhergehenden Kapitel wurden die identifizierten Analyse-Abläufe im ReKlaMe-Projekt
formal durch Abbildungen dargestellt. Diese Abbildungen und die Operatoren, aus denen sie
bestehen, müssen in diesem Kapitel nun in eine Architektur umgesetzt werden.
Neben dieser Umsetzung besteht eine weitere Aufgabe in der Konzeptionierung und Umsetzung von Hilfskomponenten, die die Abläufe unterstützen und globale Dienste zur Verfügung
stellen. So ist beispielsweise für die Zeitstempelung eine globale Uhr vonnöten. Auch Veränderungen an bestehenden oder die Induktion neuer Klassifikatoren muss einer globalen Instanz mitgeteilt werden, damit diese Veränderungen bei Analyseläufen berücksichtigt werden
können. Letztlich ist die Schaffung einer Schnittstelle zwischen Benutzer und Architektur zu
entwerfen und umzusetzen.
Die Ideen zur Umsetzung der Abläufe in eine Architektur erfolgen zunächst noch in Form
eines Grobkonzeptes. Die konkrete Planung und Durchführung der Implementation mit allen
implementationsspezifischen Details erfolgt in Kapitel 6. Auch die Formate und Datentypen,
die zum Nutz- und Kontrolldatentausch verwendet werden sollen, werden in Kapitel 6 konkret
entworfen. Dazu zählen sowohl abstrakte Metadatentypen zur Steuerung von Komponenten
als auch Nachrichten, die zur Bestätigung der erfolgreichen Abarbeitung von durchgeführten
Aufträgen zwischen Komponenten übergeben werden können.
Das Vorgehen in diesem Kapitel stellt sich daher wie folgt dar: Zunächst wird in Abschnitt
5.1 die Ableitung einer Architektur aus dem in Kapitel 4 konzeptionierten Ausführungsmodell
durchgeführt, wobei die Analyse-Abläufe abstrakt dargestellt werden. Dann erfolgt die Verfeinerung der abgeleiteten Architektur, indem zunächst in Abschnitt 5.1.1 eine Architektur für
den Analyse-Ablauf der Klassifikator-Induktion, in Abschnitt 5.1.2 eine Architektur für die
Anwendung von Klassifikatoren und in Abschnitt 5.1.3 eine Architektur für die Wartung von
Klassifikatoren auf niedriger Abstraktionsebene abgeleitet wird. In Abschnitt 5.1.4 erfolgt danach die Zusammenführung der zuvor abgeleiteten Architekturen. Anschließend befasst sich
Abschnitt 5.2 mit den Aspekten zur Erweiterung der abgeleiteten und zusammengeführten Architektur auf verteilte Szenarien, bevor in Abschnitt 5.3 eine Zusammenfassung der in diesem
Kapitel durchgeführten Arbeiten gegeben wird.
5.1. Ableitung einer Architektur aus dem
Ausführungsmodell
In diesem Abschnitt erfolgt die Ableitung einer Architektur aus dem in Kapitel 4 konzeptionierten Ausführungsmodell, welches die identifizierten Abläufe und Phasen der ReKlaMeAnalysen beschreibt. Dazu ist die Identifikation und Konzeptionierung zusätzlicher Module
und der darin enthaltenen Komponenten vonnöten. Mit dem Begriff Modul wird im Folgenden
eine Menge von Komponenten bezeichnet.
In Abbildung 5.1 ist die aus dem in Kapitel 4 konzeptionierten Ausführungsmodell abgeleitete
Architektur auf hoher Abstraktionsebene abgebildet. Es lassen sich drei große Module erkennen. Eine Verfeinerung der Abstraktionsebene wird in den Abschnitten 5.1.1, 5.1.2 und 5.1.3
73
74
K APITEL 5 - A RCHITEKTURENTWURF
Abbildung 5.1.: Architektur des ReKlaMe-Projektes auf hoher Abstraktionsebene
erfolgen. Zusätzlich zu den Komponenten, die aus den Operatoren des Ausführungsmodelles abgeleitet wurden, sind neue Komponenten hinzugekommen. Diese bieten Hilfsfunktionalitäten an, die für den Ablauf der Analyse-Vorgänge vonnöten sind und werden in den jeweiligen Abschnitten, die die Architektur auf niedriger Abstraktionsebene darstellen, aufgeführt
und beschrieben. Zu diesen Hilfskomponenten zählen beispielsweise eine globale Uhr, die im
Gesamtsystem eine einheitliche Zeitbasis darstellt, oder eine Aktualisierungs-Komponente, um
Analyseergebnisse im System verfügbar zu machen. Die nähere Beschreibung dieser Hilfskomponenten erfolgt in den Abschnitten 5.1.1 bzw. 5.1.3. Im Folgenden werden die drei erkennbaren Module der abgeleiteten Architektur auf hoher Abstraktionsebene beschrieben.
Benutzung/Steuerung/Interaktion (BSI) Über dieses Modul werden die Benutzereingaben und die System-Ausgaben verwaltet. Es handelt sich somit um die Schnittstelle des
ReKlaMe-Systemes zur Benutzerwelt. Die durch die Benutzereingaben vorgegebenen
statischen Anteile der Steuerung werden von diesem Modul übernommen. Es besteht
aus zwei Unter-Modulen, dem Eingabe- und dem Ausgabe-Modul.
Das Eingabe-Modul beinhaltet die Benutzungs-Schnittstelle und die Task-Analyse.
Zunächst wird der durchzuführende Analyse-Ablauf vom Benutzer spezifiziert. Zu den
durchführbaren Abläufen zählen die Induktion, die Anwendung und die Wartung von
Klassifikatoren. Dabei können in Abhängigkeit des gewählten Ablaufes verschiedene Alternativ-Abläufe durchgeführt werden, beispielsweise eine inkrementelle oder eine nicht-inkrementelle Klassifikator-Induktion. Der vom Benutzer gewählte AnalyseAblauf wird der Task-Analyse übergeben. Diese erfragt auf Basis dieser Informationen
die Metadaten, die bezüglich des gewählten Analyse-Ablaufes bereits im System vorliegen und für eine potentielle Analyse genutzt werden können. Dazu zählen beispielsweise die verfügbaren Datenquellen oder bereits im System vorhandene, zuvor induzierte Klassifikatoren oder Analyse-Ergebnisse. Die so selektierten Metadaten werden an
die Benutzungs-Schnittstelle zurückgegeben, die dem Benutzer in einem zweiten Schritt
nun die gefundenen Informationen präsentiert. Aus diesen Informationen können daraufhin die Metadaten zur Selektion von Daten und Klassifikatoren sowie die Metadaten
zur Parametrisierung von Prozessen ausgewählt und spezifiziert werden, die dann an die
Metadaten-Verwaltung und Steuerung übergeben werden.
74
5.1 A BLEITUNG EINER A RCHITEKTUR AUS
DEM
AUSF ÜHRUNGSMODELL
Die im Eingabe-Modul umgesetzte Steuerung kann auf drei unterschiedliche Arten umgesetzt werden:
• statisch
• dynamisch
• in einer Mischform von statisch und dynamisch
Ein großer Unterschied zwischen den dynamisch und den statisch gesteuerten Komponenten besteht vor allem darin, dass die Verbindung der Komponenten untereinander
unterschiedlich ist: Bei statisch gesteuerten Vorgängen sind immer zwei Komponenten
fest miteinander verbunden, und es besteht keine Möglichkeit der Nutzung alternativer
Komponenten. Dahingegen ist bei dynamisch gesteuerten Abläufen nicht fest vorgegeben, welche Komponente die Daten einer Vorgänger-Komponente weiter bearbeiten soll.
Eine durchgängig statische Steuerung hätte den Nachteil, dass die Erweiterbarkeit eingeschränkt wird und es somit nur erschwert möglich ist, neue Analyse-Abläufe in das
System zu integrieren. Da die Erweiterbarkeit jedoch bei der Konzeption der Architektur
für das ReKlaMe-Projekt mit im Vordergrund steht, scheidet diese Art der Steuerung aus.
Die Umsetzung der Steuerung in komplett dynamischer Weise hätte den Nachteil, dass
an den Stellen, an denen die abzuarbeitenden Vorgänge statisch vorgegeben sind, durch
die Dynamisierung ein erhöhter Aufwand zu betreiben ist, sowohl konzeptionell als auch
im Ablauf. Daher wird auch von der Umsetzung einer durchweg dynamischen Steuerung
abgesehen. In dieser Arbeit fällt die Wahl der Form der Steuerung auf eine Mischform
der beiden zuvor erwähnten Ansätze. An den Stellen innerhalb der Architektur, an denen
statische Vorgänge abzubilden sind, wird die Steuerung statisch geschehen. Dort, wo alternative Abläufe durchgeführt werden können, kommt eine dynamische Steuerung zum
Einsatz.
Das zweite Unter-Modul, die Ausgabe, zeichnet für die Verarbeitung der innerhalb des
ReKlaMe-Prozesses angefallenen Ergebnisdaten verantwortlich. Diese Daten können
zur internen Nutzung vorgesehen oder einem Benutzer über ein Visualisierungs-Modul
präsentiert werden. Zudem werden die Analyse-Ergebnisse für das System verfügbar
gemacht, indem Metadaten über die erzeugten Ergebnisse über eine AktualisierungsKomponente in ein entsprechendes Metadaten-Verwaltungs-System eingetragen werden.
Metadaten-Verwaltung/Steuerung (MVS) Das Modul zur Metadaten-Verwaltung und
Steuerung übernimmt die dynamische Steuerung der einzelnen Abläufe innerhalb von
ReKlaMe-Analysen sowie die Speicherung und Anlieferung verschiedener Daten, die
an unterschiedlichen Stellen während einer ReKlaMe-Analyse anfallen oder benötigt
werden. Dazu existieren drei Unter-Module, je eines für jeden identifizierten AnalyseAblauf. Die Eingaben werden vom BSI-Modul an eines der drei Module zur Steuerung des durchzuführenden Ablaufes übergeben, dann durch das entsprechende Modul
verarbeitet und an das korrespondierende Unter-Modul des Moduls zur Steuerung der
Analyse-Abläufe übergeben.
Zusätzlich beherbergt dieses Modul weitere Hilfs-Komponenten, die AktualisierungsKomponente und die globale Uhr. Die Aktualisierungs-Komponente wird vom AusgabeModul über neu erzeugte, erweiterte oder gewartete Klassifikatoren, globale Modelle
und neu generierte Klassifikationsergebnisse informiert. Bekommt sie die Nachricht über
die Generierung neuer Daten durch das System, so fügt sie die zugehörigen Metadaten,
die vom Ausgabe-Modul übergeben werden, zu den einzelnen Metadaten-Verwaltungs/Steuerungs-Komponenten hinzu. Somit stehen diese Datensätze, Klassifikatoren und
globalen Modelle für spätere Analysen zur Verfügung. Die globale Uhr dient der einheitlichen Zeitgebung für das Gesamt-System.
75
75
76
Analyse-Abläufe (AA) Dieses Modul beinhaltet Module zur Ausführung der identifizierten
Analyse-Abläufe sowie ein Modul zur Verwaltung der verfügbaren Datenquellen. Jedes
der drei Module zur Induktion, Anwendung oder Wartung ist mit dem Modul zur Verwaltung der Datenquellen verbunden und kann mit ihm durch die dynamische Steuerung
Daten austauschen. Das Modul zur Verwaltung der verfügbaren Datenquellen beinhaltet
drei Unter-Module: ein Repository für Klassifikatoren, eine Datensenke zur Speicherung von Klassifikationsergebnissen (die später auch als Datenquelle zum Auslesen von
Klassifikatoren dienen wird) sowie ein Modul zur Verwaltung der Datenquellen für Trainingsdaten oder Instanzdaten.
Auf dieser Abstraktionsebene können die drei Phasen der Induktion, Anwendung und Wartung
von Klassifikatoren auf die Module der Metadaten-Verwaltung/Steuerung sowie der AnalyseAbläufe analog zum Ausführungsmodell abgebildet werden. Daher folgt im nächsten Abschnitt
die nähere Betrachtung der einzelnen zur Durchführung der Analyseschritte notwendigen TeilArchitekturen. Der Aspekt der Verteiltheit der Komponenten, so wie sie im Ausführungsmodell
vorgesehen ist, findet zunächst keine Beachtung. Es wird vorerst davon ausgegangen, dass
alle Komponenten lokal an einem Ort vorliegen. Nach Zusammenführung der Architekturen
aller drei Analyse-Abläufe in Abschnitt 5.1.4 folgt dann die Erweiterung der Architektur auf
verteilte Szenarien in Abschnitt 5.2.
5.1.1. Architektur zur Induktion von Klassifikatoren
Die Basis für die Architektur zur Induktion von Klassifikatoren bilden die in Abschnitt 4.4.1
ausgeführten Überlegungen. Abbildung 5.2 zeigt die Architektur zur Induktion von Klassifikatoren.
Abbildung 5.2.: Architektur der Klassifikator-Induktion
Die hierarchische Schachtelung der Komponenten und deren Zugehörigkeit zu einem der drei
Haupt-Module sei durch den Namen der Komponenten spezifiziert. So gelte im Folgenden,
dass die Komponente AA:BB:CC den Namen CC trägt und im Unter-Modul BB lokalisiert ist,
welches Modul AA zugehörig ist.
Zusätzlich zu den aus dem Ausführungsmodell abgeleiteten Komponenten werden weitere
Komponenten benötigt. Ein Überblick über alle Komponenten, die am Analyse-Ablauf der
Klassifikator-Induktion beteiligt sind, sei im Folgenden gegeben.
76
DEM
BSI:Eingabe:BS Die Benutzungs-Schnittstellen-Komponente BS ist eine statisch gesteuerte und statisch angebundene Komponente. Sie nimmt in einem ersten Schritt Informationen vom Benutzer über den durchzuführenden Analyse-Ablauf entgegen. Diese übergibt sie an die Komponente zur Task-Analyse TA, die entsprechend der durchzuführenden Analyse korrespondierende Metadaten über die zur Verfügung stehenden Klassifikatoren, Datenquellen und Klassifikationsergebnisse zurück gibt. In einem zweiten
Schritt werden diese Informationen dem Benutzer präsentiert, der anhand dieser Daten
anschließend einen genauen Analyse-Auftrag erteilen kann. Der Benutzer wählt dazu
die zu verwendenden Klassifikatoren und Datenquellen, die zu verwendenden AnalyseVerfahren und deren Parameter. Diese Informationen werden anschließend an die nachfolgende Metadaten-Verwaltungs-/Steuerungs-Komponente weitergegeben, um die Analyse durchzuführen.
BSI:Eingabe:TA Die Komponente zur Task-Analyse TA analysiert die Eingaben des Benutzers im Hinblick auf die durchzuführende Analyse. Auf Basis dieser Informationen wird nun in der Metadaten-Verwaltungs-/Steuerungs-Komponente nach verfügbaren Ressourcen gesucht, die dieser Analyse als Grundlage dienen können. Dazu zählen
Datenquellen, bereits induzierte Klassifikatoren oder bereits erzeugte Klassifikationsergebnisse. Wenn alle Informationen zusammengetragen wurden, so werden diese an
BSI:Eingabe:BS zurückgegeben. Die Abläufe dieser Komponente sowie deren Anbindung an andere Komponenten ist ebenfalls statisch ausgeführt, wobei jedoch die Wahl
der korrespondierenden Metadaten-Verwaltungs-/Steuerungs-Komponente von dem zur
Durchführung identifizierten Analyse-Ablauf vorgegeben wird.
MVS:IMVK Die Induktions-Metadaten-Verwaltungs-Komponente IMVK extrahiert die verschiedenen Metadatensätze zur dynamischen Steuerung des Analysevorganges. Zu diesen Metadatensätzen zählen Informationen zur Selektion von Klassifikatoren und Trainingsdaten sowie zur Parametrisierung von Induktions-Algorithmen. Die Metadaten
stammen aus dem eigenen Metadatenrepository und wurden vom Benutzer für die durchzuführende Analyse ausgewählt. Anhand der Benutzerangaben wird zudem der durchzuführende Induktions-Schritt ((inkrementelle) Induktion oder Meta-Lernen) festgelegt.
Folgend besteht die Aufgabe dieser Komponente in der Steuerung der Abläufe, die zur
Durchführung des Analyse-Ablaufes der Induktion vonnöten sind. Dies geschieht, indem
steuernde Metadaten an die entsprechenden Komponenten versendet werden.
Das Verhalten dieser Komponente hängt vom durchzuführenden Induktions-Schritt ab,
wobei folgende Schritte unterstützt werden sollen:
• (Inkrementelle) Klassifikator-Induktion: Die Metadaten zur Selektion der Trainingsdaten werden (im Falle der inkrementellen Induktion parallel mit den Metadaten zur Basisklassifikator-Selektion) an die jeweilige Komponente, die die entsprechende Selektion durchführt, weitergereicht. Es wird auf eine Antwort zur Bestätigung gewartet, dass die entsprechend selektierten Daten an der Komponente vorliegen, die die Induktion durchführt. Nach Empfang der Bestätigungen wird der Metadatensatz zur Parametrisierung des Induktions-Algorithmus an die entsprechende
Komponente weitergegeben.
Im Falle der Induktion ist dies AA:(I)IK.
• Meta-Lernen: Der erste Metadatensatz zur Basisklassifikator-Selektion wird BSK
übergeben. Nach Empfang der Bestätigung von BSK, den zu selektierenden Klassifikator an AA:MLK erfolgreich ausgeliefert zu haben, wiederholt sich dieses Vorgehen, bis alle Basisklassifikatoren an den Meta-Lerner ausgeliefert wurden, die für
den aktuell durchzuführenden Meta-Lern-Vorgang benötigt werden. Diese werden
durch die Eingaben des Benutzers spezifiziert. Sind alle Basisklassifikatoren an den
77
77
78
Meta-Lerner übergeben, so kann eine Nachricht an diesen übermittelt werden, die
den Meta-Lern-Vorgang initiiert und steuert.
Die für den Meta-Lern-Vorgang verantwortliche Komponente ist in diesem Falle
AA:MLK.
MVS:AK Die Aktualisierungs-Komponente AK dient der Aktualisierung der in MVS:IMVK
vorgehaltenen Metadaten über Klassifikatoren, Analyse-Ergebnisse und Datenquellen.
Auch hier handelt es sich um eine statisch angebundene und gesteuerte Komponente. Sobald ein neues Analyse-Ergebnis an die Verwertungs-Komponente BSI:VK übergeben
wurde, übermittelt diese die zugehörigen Metadaten an MVS:AK. Die AktualisierungsKomponente fügt diese Metadaten dann in den von MVS:IMVK gehaltenen Datenbestand
ein.
AA:DSK Die Daten-Selektions-Komponente DSK selektiert auf Basis von Metadaten eine
Menge von Trainingsdaten und übergibt diese an eine nachfolgende Komponente. Die
erfolgreiche Übergabe wird mit einer Nachricht an eine steuernde Komponente quittiert.
Die Metadaten bestimmen dabei die zu selektierenden Daten, die Adresse und Zugangsdaten der dazu notwendigen Quelle sowie die Adresse, an die die selektierten Daten
und die Quittung übersendet werden sollen. Die Steuerung dieser Komponente erfolgt
dynamisch. So können zur Laufzeit anhand von steuernden Metadaten verschiedene Datenquellen und -senken festgelegt werden.
Im Falle der Klassifikator-Induktion erhält diese Komponente von MVS:IMVK die Metadaten zur Selektion der Trainingsdaten, die der Induktion zugrunde liegen sollen. Sie
führt die Selektion durch, indem sie die entsprechende Selektion mittels AA:DQ:TD delegiert. Dann übergibt sie die selektierten Daten in einem entsprechenden Datenformat
an AA:(I)IK und sendet eine Bestätigung der erfolgreichen Übergabe der Trainingsdaten an MVS:IMVK.
AA:DQ:TD Die Komponente zur Selektion von Trainingsdaten TD nimmt die Metadaten entgegen, die zur Selektion benötigt werden, und selektiert die angeforderten Daten. Anschließend gibt sie die selektierten Daten an eine nachfolgende Komponente, die durch
die Metadaten spezifiziert wird, zurück. Durch die zur Laufzeit mögliche Konfigurierbarkeit der Komponente, an die die selektierten Daten zurückgegeben werden sollen, ist
die Steuerung dieser Komponente ebenfalls dynamisch.
Im Falle der Induktion stammen die Metadaten von MVS:IMVK, die Ergebnisse werden
an AA:DSK übergeben.
AA:BSK Die Basisklassifikator-Selektions-Komponente BSK nimmt im Falle einer inkrementellen Klassifikator-Induktion einen Metadatensatz zur Selektion des zu erweiternden Klassifikators entgegen. Die Selektion wird durch Übergabe des entsprechenden Metadatensatzes an eine Klassifikator-Quelle initiiert. Der empfangene Klassifikator wird
dann an eine durch die übergebenen Metadaten spezifizierte, nachfolgende Komponente
weitergegeben. Die erfolgreiche Übergabe des Klassifikators wird durch Senden einer
quittierenden Nachricht an die initiierende Komponente signalisiert. Auch hier findet
dynamische Steuerung statt.
Während des Ablaufes der Induktion stammen die Metadaten von MVS:IMVK. Die Anfrage nach einem Klassifikator wird an AA:DQ:KR gestellt. Der selektierte Klassifikator
wird dann an AA:(I)IK übergeben, und nach erfolgreicher Übergabe wird eine Bestätigung an MVS:IMVK gesendet.
AA:DQ:KR Die Komponente des Basisklassifikator-Repositories KR nimmt einen Metadatensatz entgegen, selektiert auf dessen Basis einen Klassifikator und gibt diesen an eine
dynamisch durch die Metadaten spezifizierte Komponente zurück.
78
DEM
Während des Ablaufes der Induktion stammt die Anfrage von AA:BSK, an die auch der
Klassifikator zurückgegeben wird.
AA:(I)IK Die (Inkrementelle) Induktions-Komponente (I)IK wartet, sofern der auszuführende Ablauf eine Induktion ist, auf die Eingabe eines Metadatensatzes, der die
Induktion eines Klassifikators initiiert und den anzuwendenden Algorithmus parametrisiert. Die zur Induktion benötigten Trainingsdaten und im Falle der inkrementellen
Induktion der zu erweiternde Klassifikator werden ebenfalls von (I)IK entgegengenommen. Der induzierte oder erweiterte Klassifikator wird schließlich an eine nachfolgende Komponente übergeben. Die Steuerung erfolgt dynamisch zur Laufzeit durch die
übergebenen Metadaten, die den Algorithmus parametrisieren und die Datenquellen und
-senken festlegen.
Während des Ablaufes der Klassifikator-Induktion stammen die Metadaten zur Steuerung des Induktions-Prozesses von MVS:IMVK. Die Trainingsdaten wurden von
AA:DSK übergeben. Im Falle einer inkrementellen Induktion wurde zudem durch
AA:BSK ein Basisklassifikator bereitgestellt. Der induzierte Klassifikator wird an
BSI:Ausgabe:VK übergeben.
AA:MLK Die Meta-Lern-Komponente MLK nimmt eine Reihe von Klassifikatoren auf und
speichert diese für den Meta-Lern-Vorgang zwischen. Sind alle Klassifikatoren übergeben, wartet sie auf einen Metadatensatz zur Initiierung des Meta-Lern-Vorganges.
Das erzeugte globale Modell wird einer nachfolgenden Komponente nach Abschluss
des Meta-Lern-Vorganges zur Verfügung gestellt. Die Steuerung erfolgt analog zu den
vorigen Analyse-Komponenten dynamisch.
Im Falle des Ablaufes des Meta-Lernens werden die Klassifikatoren von AA:BSK übergeben und von AA:MLK zwischengespeichert. Nach Empfang der parametrisierenden
Metadaten von MVS:IMVK wird der Meta-Lern-Vorgang initiiert. Das erzeugte globale
Modell wird BSI:Ausgabe:VK zur weiteren Verarbeitung übergeben.
BSI:Ausgabe:VK Die Verwertungs-Komponente VK nimmt den induzierten, erweiterten
Klassifikator oder das globale Modell des Meta-Lerners sowie einen Metadatensatz entgegen. Auf Basis der steuernden Metadaten wird anschließend die Visualisierung oder
die Speicherung des Klassifikators oder globalen Modelles initiiert, indem der Klassifikator oder das globale Modell an eine der beiden nachfolgenden Komponenten weitergereicht wird. Zusätzlich werden Metadaten über die Analyse-Ergebnisse und deren
Verwertung erhoben. Diese können an eine nachfolgende Komponente übergeben werden. Auch hier findet also dynamische Steuerung statt.
Während des Induktions-Ablaufes wird der induzierte bzw. erweiterte Klassifikator oder das globale Modell von AA:(I)IK oder AA:MLK entgegengenommen.
Die von MVS:IMVK entgegen genommenen Metadaten bestimmen nun, ob der
Klassifikator oder das globale Modell an BSI:Ausgabe:Speicherung oder
BSI:Ausgabe:Visualisierung übergeben werden. Die erhobenen Metadaten über den erzeugten oder erweiterten Klassifikator werden der AktualisierungsKomponente MVS:AK übergeben, damit diese in den Datenbestand der jeweiligen
Metadaten-Verwaltungs-/Steuerungs-Komponente eingepflegt werden können und somit für nachfolgende Analysen zur Verfügung stehen.
5.1.2. Architektur zur Anwendung von Klassifikatoren
Die Basis für die Architektur zur Anwendung von Klassifikatoren bilden die in Abschnitt 4.4.2
ausgeführten Überlegungen. Abbildung 5.3 zeigt die Architektur zur Anwendung von Klassifikatoren auf niedriger Abstraktionsebene. Die nachfolgenden Komponenten sind am Ablauf der
79
79
80
Abbildung 5.3.: Architektur der Klassifikator-Anwendung
Klassifikator-Anwendung beteiligt und werden bezüglich ihrer Funktionalität vorgestellt. Sofern eine Komponente bereits in Abschnitt 5.1.1 mit identischer Funktionalität vorkommt, wird
hier auf die erneute Beschreibung der Funktionalität verzichtet und die Komponente lediglich
in ihren Verbindungen zu anderen Komponenten beschrieben.
BSI:Eingabe:BS Verhalten analog zu BSI:Eingabe:BS in Abschnitt 5.1.1.
Während des Ablaufes der Klassifikator-Anwendung werden die vom Benutzer ausgewählten Eingaben und Metadaten zur Ausführung der Analyse an MVS:AMVK übergeben.
BSI:Eingabe:TA Verhalten analog zu BSI:Eingabe:TA in Abschnitt 5.1.1.
Im Falle der Klassifikator-Anwendung werden die Metadaten aus MVS:AMVK selektiert.
MVS:AMVK Die Anwendungs-Metadaten-Verwaltungs-Komponente AMVK extrahiert die
verschiedenen Metadatensätze zur dynamischen Steuerung des Analyse-Ablaufes der
Klassifikator-Anwendung. Der vom Benutzer aus den beiden möglichen AnwendungsAbläufen ausgewählte Ablauf bestimmt folgend die weiteren Schritte der Durchführung
der Analyse.
• Naive Klassifikator-Anwendung: Der Datensatz zur Selektion der zu klassifizierenden Instanzen wird parallel mit dem Datensatz zur Selektion des anzuwendenden Klassifikators an die jeweilige Selektions-Komponente übergeben. Sobald die Instanz-Daten bzw. der Klassifikator an der Klassifikations-Komponente
AA:KK anliegen, senden die jeweilig verantwortlichen Selektions-Komponenten
eine Bestätigung an MVS:AMVK. Darauf folgend kann dann der Datensatz zur Parametrisierung des Klassifikations-Algorithmus an AA:KK übergeben und somit
die Klassifikation initiiert werden.
• Klassifikation durch Selection-Graph-Ableitung: Der Datensatz zur Selektion
des anzuwendenden Klassifikators wird zusammen mit der Information, den selektierten Klassifikator an AA:SGAK zu senden, an AA:BSK übergeben. Nach Emp-
80
DEM
fang der Bestätigung von AA:BSK, den Klassifikator erfolgreich an AA:SGAK ausgeliefert zu haben, wird die Methode der Selection-Graph-Ableitungs-Komponente
AA:SGAK zur Wandlung des Klassifikators aufgerufen.
MVS:AK Verhalten analog zu MVS:AK in Abschnitt 5.1.1.
Bei der Klassifikator-Anwendung werden die Metadaten, die von BSI:Ausgabe:VK
übermittelt wurden, in den Datenbestand von MVS:AMVK eingepflegt.
AA:DSK Verhalten analog zu AA:DSK in Abschnitt 5.1.1.
Während des Ablaufes der Anwendung eines Klassifikators werden anstelle der Trainingsdaten hier die zu klassifizierenden Instanzen selektiert und an AA:KK übergeben.
Die Bestätigung der erfolgreichen Auslieferung der Instanz-Daten wird an MVS:AMVK
gesandt, von wo auch die Metadaten zur Selektion kamen.
AA:DQ:ID Verhalten analog zu AA:DQ:TD in Abschnitt 5.1.1.
Im Falle der Anwendung eines Klassifikators werden hier die zu klassifizierenden Instanzen und nicht Trainingsdaten selektiert. Zusätzlich ist hier das Verhalten in Abhängigkeit
des durchzuführenden Ablaufes zu unterscheiden:
• Naive Klassifikator-Anwendung: Die selektierten Instanzen werden an AA:DSK
zurückgegeben.
• Klassifikation durch Selection-Graph-Ableitung: Die selektierte InstanzenMenge, die eine Zielklasse der Klassifikation darstellt, wird an AA:DBAGK zurückgegeben.
AA:BSK Verhalten analog zu AA:BSK in Abschnitt 5.1.1.
Während des Ablaufes der Anwendung eines Klassifikators wird der anzuwendende
Klassifikator selektiert und in Abhängigkeit des auszuführenden Tasks weitergegeben:
• Naive Klassifikator-Anwendung: Der selektierte Basisklassifikator wird an
AA:KK übergeben.
• Klassifikation durch Selection-Graph-Ableitung: Der selektierte Basisklassifikator wird an AA:SGAK übergeben.
Die Bestätigung der erfolgreichen Auslieferung des anzuwendenden Klassifikators an
eine der beiden nachfolgenden Komponenten wird anschließend an MVS:AMVK gesandt.
AA:DQ:KR Verhalten analog zu AA:DQ:KR in Abschnitt 5.1.1.
Im Falle der Anwendung eines Klassifikators stammen die Metadaten zur Selektion eines Klassifikators ebenfalls von AA:BSK, und der Klassifikator wird ebenfalls an diese
Komponente zurückgegeben.
AA:KK Die Klassifikations-Komponente KK nimmt einen Klassifikator, eine Menge zu klassifizierender Instanz-Daten und eine parametrisierende Metadatenmenge entgegen. Die
Klassifikation wird ausgeführt, und die Ergebnisklassen werden an eine nachfolgende
Komponente zur weiteren Verarbeitung übergeben. Die Steuerung erfolgt dynamisch.
Während des Ablaufes der Klassifikator-Anwendung stammen die Instanz-Daten von
AA:DSK, der Klassifikator von AA:BSK und die erzeugten Ergebnisdatenmengen werden an BSI:VK zur weiteren Verarbeitung übergeben.
AA:SGAK Die Selection-Graph-Ableitungs-Komponente SGAK nimmt einen Basisklassifikator, aus dem der Selection Graph abgeleitet werden soll, entgegen. Die abgeleiteten
81
81
82
Selection Graphs werden an eine nachfolgende Komponente weitergegeben, die diese
weiterverarbeiten kann. Die Steuerung dieser Komponente erfolgt statisch.
Im Falle der Anwendung eines Klassifikators wird der Aufruf zur Ableitung der Selection Graphs von MVS:AMVK entgegengenommen. Der Basisklassifikator stammt von
AA:BSK und die erzeugte Selection-Graph-Menge wird an AA:DBAGK weitergegeben,
die daraus Datenbankabfragen generieren kann.
AA:DBAGK Die Datenbank-Abfrage-Generierungs-Komponente DBAGK nimmt einen Metadatensatz zur Steuerung des Ablaufes sowie eine Menge von Selection Graphs entgegen.
Sie wandelt die Selection Graphs in Datenbank-Abfragen. Diese Abfragen können dann
auf eine relationale Datenbank angewendet werden, um eine Klassifikation der darin enthaltenen Instanz-Datensätze durchzuführen. Die Lokalisierung der Datenbank, auf der
die Abfragen ausgeführt werden sollen, erfolgt mittels des entgegengenommenen Metadatensatzes. Dieser Ablauf ist in einen dynamischen Rahmen eingebettet.
Im Falle der Anwendung eines Klassifikators werden die Selection Graphs von
AA:SGAK entgegengenommen. Die erzeugten Datenbankabfragen werden auf
AA:DQ:ID angewandt. Nach erfolgreicher Anfrage an AA:DQ:ID und Empfang der
Ergebnisse der Abfrage wird eine Bestätigung an MVS:AMVK übergeben. Sind alle
Abfragen erfolgreich gestellt worden, so sendet DBAGK eine spezielle Bestätigung, die
MVS:AMVK signalisiert, dass alle Zielklassen selektiert wurden. Diese werden dann als
Klassifikationsergebnis an BSI:Ausgabe:VK übergeben.
BSI:Ausgabe:VK Die Verwertungs-Komponente VK nimmt eine Menge von Klassifikationsergebnissen entgegen. Anschließend werden die Ergebnisse an eine nachfolgende
Komponente zur Weiterverarbeitung übergeben. Die Steuerung erfolgt dynamisch über
einen von MVS:AMVK übergebenen Metadatensatz, der die weitere Verarbeitung der
übergebenen Ergebnisse steuert.
Im Falle der Anwendung eines Klassifikators verhält sich diese Komponente in
Abhängigkeit des durchzuführenden Ablaufes wie folgt:
• Naive Klassifikator-Anwendung: Die Verwertungs-Komponente VK nimmt die
Klassifikationsergebnisse von AA:KK sowie einen Metadatensatz zur Bestimmung
der weiteren Verarbeitung der Ergebnisse entgegen. Entsprechend der dynamisch
steuernden Metadaten werden die Ergebnisse einer nachfolgenden Komponente zur
Visualisierung oder Speicherung übergeben.
• Klassifikation durch Selection-Graph-Ableitung: Die Verwertungs-Komponente
VK nimmt die Ergebnismengen der Klassifikator-Anwendung von AA:DBAGK sowie einen Metadatensatz von MVS:AMVK entgegen. Der Metadatensatz bestimmt
die Weiterverarbeitung der Zielklassen, die von einer nachfolgenden Komponente
visualisiert oder der Speicherung zugeführt werden können.
Unabhängig vom durchzuführenden Ablauf werden noch Metadaten über die AnalyseErgebnisse erzeugt und an MVS:AK übergeben. Dieser Vorgang unterliegt statischer
Steuerung.
5.1.3. Architektur zur Wartung von Klassifikatoren
Die Basis für die Architektur zur Wartung von Klassifikatoren bilden die in Abschnitt 4.4.3
ausgeführten Überlegungen. Abbildung 5.4 zeigt die Architektur zur Wartung von Klassifikatoren auf niedriger Abstraktionsebene. Die Klassifikator-Wartung unterscheidet sich von der
Induktion nur in zwei zusätzlich vorhandenen Komponenten:
82
DEM
Abbildung 5.4.: Architektur der Klassifikator-Wartung
MVS:GU Die Globale Uhr GU dient der einheitlichen Zeitgebung für das gesamte ReKlaMeSystem. Auf Basis einer globalen Uhr soll allen Komponenten an allen verteilten Stellen
im ReKlaMe-System eine einheitliche Zeit zur Verfügung stehen, anhand derer eine Zeitstempelung erfolgen kann. Diese globale Zeit wird beispielsweise von AA:IVK benötigt,
um einen zu wartenden Klassifikator mit einem Zeitstempel als ungültig zu markieren.
Der Zugriff erfolgt über den Aufruf einer Methode zur Abfrage der Zeit. Die Methode sendet dann eine Nachricht zurück, die die aktuelle Zeit in einem entsprechenden
Format beinhaltet. Aufgrund der Komplexität der Schaffung einer exakten Zeitübergabe über ein asynchrones Netzwerk wird hier nicht gefordert, dass die Zeitübergabe in
Realzeitbedingungen erfolgt. Vielmehr wird diese Komponente prototypisch entworfen
und implementiert, da die Schaffung einer genauen Zeitübergabe innerhalb eines asynchronen Netzwerkes den Rahmen dieser Arbeit übersteigt. Für den weiteren Verlauf wird
angenommen, dass GU über eine Methode verfügt, die in der Lage ist, ohne Zeitverlust
die aktuelle Zeit an anfragende Komponenten zu übergeben.
AA:IVK Die Invalidierungs-Komponente AA:IVK dient der Invalidierung von Klassifikatoren
oder globalen Modellen, die im Ablauf der Wartung neu erzeugt oder erweitert werden.
Vor der erneuten Induktion eines Klassifikators anhand von neuen Trainingsdatensätzen
oder der erneuten Ableitung eines globalen Modelles aus einer Menge von Basisklassifikatoren durch einen Meta-Lerner wird der aktuelle Klassifikator durch einen Zeitstempel von AA:IVK ungültig gestempelt. Den dazu benötigten Zeitstempel kann AA:IVK
anhand der Daten der Abfrage der globalen Zeit von MVS:GU erzeugen. Der anschließend neu generierte Klassifikator wird ins Klassifikator-Repository eingefügt und kann
anhand seines fehlenden Transaktionszeitende-Stempels (TZE) als aktuell identifiziert
werden.
Sonstige Abläufe und Komponenten verlaufen analog zur Klassifikator-Induktion, die in Abschnitt 5.1.1 ausführlich beschrieben wurde.
83
83
84
5.1.4. Zusammenführung der Architekturen zur Induktion, Anwendung
und Wartung
Nachdem in den vorigen Abschnitten die Architekturen für die Induktion, die Anwendung und
die Wartung von Klassifikatoren aus dem in Kapitel 4 konzeptionierten Ausführungsmodell
abgeleitet wurden, erfolgt nun deren Zusammenführung zu einer Gesamt-Architektur, die das
ReKlaMe-Projekt beschreiben wird.
Abbildung 5.5.: Gesamt-Architektur des ReKlaMe-Projektes
Die zusammengeführte Architektur ist in Abbildung 5.5 dargestellt. Komponenten, die in mehr
als einem der vorhergehenden Architekturen der einzelnen Analyse-Abläufe auftreten, oder
solche, die Spezialisierungen einer abstrakten Komponente sind, werden in abstrakten Komponenten zusammengefasst. Weiterhin ergibt sich im Bereich der abstrakten Komponenten die
Möglichkeit der Erweiterbarkeit der gesamten Architektur, indem einer abstrakten Komponente neue Implementationen mit anderer oder erweiterter Funktionalität hinzugefügt werden.
So ist die Gesamt-Architektur durch Implementation entsprechender Komponenten um neue
Analyse-Abläufe erweiterbar. Folgende Komponenten können als abstrakt identifiziert werden:
Metadaten-Verwaltungs-/Steuerungs-Komponente MVS:MVSK Die
Komponente zur Metadatenverwaltung und Steuerung beinhaltet die jeweiligen MetadatenVerwaltungs-/Steuerungs-Komponenten (MVSK) der drei Analyse-Abläufe. Jede dieser
drei MVSK erhält von der Task-Analyse BSI:Eingabe:TA die aus den Benutzereingaben extrahierten Metadaten zur Steuerung des jeweiligen Analyse-Ablaufes und
isoliert diese voneinander. Zu dem Zeitpunkt, zu dem sie dann an einer Komponente
zur Durchführung der Analyse benötigt werden, werden sie dann an die entsprechende
Komponente übermittelt. Zusätzlich übernimmt diese Komponente die Steuerung der
Abläufe der Analyse-Komponenten.
Klassifikator-Verarbeitung AA:KV In dieser abstrakten Komponente werden die Komponenten zur Implementierung der Analyse-Algorithmen zur Induktion und Anwendung
von Klassifikatoren zusammengefasst, da die angebundenen Komponenten identisch
sind. Sie unterscheiden sich in der Übergabe von Trainingsdaten an die Induktions- und
84
5.2 E RWEITERUNG DER G ESAMT-A RCHITEKTUR UM
DEN
A SPEKT
DER
V ERTEILTHEIT DER KOMPONENTEN
Instanzdaten an die Klassifikations-Komponente sowie in dem die Analyse steuernden
Metadatensatz. Bezüglich der Ausgabe werden im Falle der Induktion Klassifikatoren,
im Falle der Klassifikation Zielklassen an BSI:Ausgabe:VK übergeben.
Ergebnis-Verarbeitung BSI:Ausgabe:EV Die Ergebnis-Verarbeitung beinhaltet zwei
implementierende Komponenten zur Ergebnis-Verarbeitung: eine Komponente dient
der Speicherung von Ergebnisdaten, eine weitere der Visualisierung und Präsentation
gegenüber einem Benutzer. Hier sind die angebundenen Komponenten sowie die Signaturen identisch, und eine Erweiterung der Gesamt-Architektur ist durch Implementation
weiterer Komponenten mit anderer oder erweiterter Funktionalität möglich.
Neben den abstrakten Komponenten sind die in den vorhergehenden Architekturen beschriebenen Komponenten übernommen worden. Ihre Funktionalität gleicht den in den Abschnitten
5.1.1, 5.1.2 und 5.1.3 beschriebenen Funktionalitäten.
5.2. Erweiterung der Gesamt-Architektur um den Aspekt der
Verteiltheit der Komponenten
Aufgrund der gewählten J2EE-EJB-Technologie bedarf es zur Erweiterung der abgeleiteten
Gesamt-Architektur auf ein verteiltes Szenario keiner zusätzlichen Komponenten. Die Funktionalität zur Unterstützung von Verteiltheit muss vielmehr bei der Konzeptionierung der bereits vorhandenen Komponenten und deren Verbindungen untereinander berücksichtigt werden. Die EJB-Architektur ermöglicht die Schaffung von verteilten Komponenten, die untereinander Zugriff auf ihre Methoden, Zustände und Daten erlauben. Dazu stehen Stubs in Form von
Home- und Remote-Interface Verfügung, die es einer Komponente ermöglichen, die Dienste einer anderen Komponente zu nutzen. Um die Schaffung und Umsetzung der KommunikationsInfrastruktur muss sich der Entwickler dabei nicht kümmern, da diese durch die Dienste des
EJB-Containers (siehe dazu Abschnitt 3.5.3) bereits gegeben ist. Ausführliche Informationen
über die EJB-Architektur und deren Kommunikationsstrukturen finden sich in [MH02] sowie
in Abschnitt 3.5 und in Anhang B.2.
Um eine Induktion, Anwendung oder Wartung eines Klassifikators auf Grundlage verteilter
Datenquellen durchführen zu können, bedarf es der Zugriffsmöglichkeit auf verschiedene, verteilte Datenquellen durch die Komponenten DSK und BSK. Auch die an der Analyse beteiligten
Komponenten müssen es ermöglichen, von verteilt vorliegenden MVK zugreifbar zu sein und
Daten von verteilt vorliegenden DSK oder BSK entgegen nehmen zu können. Zusätzlich können
Datenbankabfragen von DBAGK auf Basis von Selection Graphs von SGAK eines anderen Systemes erzeugt und auf die Datenquelle eines dritten Systemes angewandt werden.
Die Erweiterung der Architektur für ein verteiltes Szenario bedarf somit sowohl der Schaffung
einer Kommunikation zwischen den Komponenten als auch der Ermöglichung des Zugriffes
auf die Methoden der verteilten Komponenten durch entfernte Komponenten. Da der Einsatz
der EJB-Architektur in Abschnitt 3.4 beschlossen wurde, kann die Unterstützung von Verteiltheit durch die Implementation der Komponenten als EJBs erreicht werden, die die eingangs
erwähnten Möglichkeiten des Zugriffes auf Dienste verteilter Komponenten ermöglichen. Die
Steuerung und Lokalisierung der anzusprechenden, verteilten Komponenten muss anhand der
Metadaten durchführbar sein. Die Aufteilung der an einer Analyse beteiligten Komponenten
muss über die Metadaten durch den Benutzer oder das System bestimmt werden können. Durch
eine entsprechende Modellierung der Metadatenformate ist dieses Ziel umsetzbar. Die Konzeptionierung dieser Metadaten-Formate wird in Kapitel 6 durchgeführt werden.
85
85
86
Z ENTRALE KOMPONENTE
D EZENTRALE KOMPONENTE
• BSI:Eingabe:TA
• AA:BSK
• MVS:MVSK(={AMVK,IMVK,WMVK})
• AA:DSK
• AA:IVK
• AA:KV(={(I)IK,KK})
• BSI:Ausgabe:VK
• AA:ML
• BSI:Ausgabe:EV(={S,V})
• AA:SGAK
• MVS:GU
• AA:DBAGK
• AA:DQ:{ID,KE,KR,TD}
Tabelle 5.1.: Einteilung der Komponenten der ReKlaMe-Gesamt-Architektur in zentral und dezentral angebundene Komponenten
Die Aufteilung der Komponenten der ReKlaMe-Gesamt-Architektur in zentral und dezentral
angebundene Komponenten innerhalb der ReKlaMe-Analyse-Abläufe ist in Tabelle 5.1 aufgezeigt. Sie richtet sich nach der geforderten Funktionalität der Architektur. Dabei werden
dezentrale Komponenten mehrfach innerhalb der Gesamt-Architektur an jedem Ort in einer Instanz vorgehalten. Somit wird es an jedem Ort ermöglicht, autonom Analysen durchführen zu
können. Zentral angebundene Komponenten liegen zusätzlich zu den verteilten Orten noch zentral vor. Somit ist es auch möglich, Analyse-Abläufe auf verteilten Datenquellen mit verteilten
Analyse-Komponenten durchzuführen, die zentral gesteuert werden können.
Nachdem in Kapitel 4 ein Ausführungsmodell für Analysen im ReKlaMe-Kontext entworfen
wurde, erfolgte in Abschnitt 5.1 daraus die Ableitung einer Architektur, zunächst auf hoher
Abstraktionsebene. Anschließend wurde in Abschnitt 5.1.1 die Architektur für den AnalyseAblauf der Klassifikator-Induktion auf niedriger Abstraktionsebene aus der in Abschnitt 4.4.1
konzeptionierten operationalisierten Beschreibung des Ablaufes der Klassifikator-Induktion
abgeleitet. Analog zu diesem Vorgehen wurden in den Abschnitten 5.1.2 und 5.1.3 partielle Architekturen zur Anwendung und Wartung von Klassifikatoren auf niedriger Abstraktionsebene
aus den in den Abschnitten 4.4.2 und 4.4.3 konzeptionierten operationalisierten Beschreibungen der Abläufe der Anwendung und Wartung von Klassifikatoren abgeleitet. Dabei wurden
eine Globale Uhr und eine Aktualisierungs-Komponente als zusätzlich benötigte Hilfskomponenten entworfen und in der Architektur positioniert.
Diese drei abgeleiteten Architekturen wurden anschließend zu einer Gesamt-Architektur auf
niedriger Abstraktions-Ebene zusammengefügt. Diese Gesamt-Architektur beschreibt alle drei
in ReKlaMe durchführbaren Analyse-Abläufe zur Induktion, Anwendung und Wartung von
Klassifikatoren, jedoch ohne den Aspekt der Verteiltheit zu berücksichtigen. Diese Erweiterung
um den Aspekt der Verteiltheit von Datenquellen und Analyseschritten wurde abschließend in
Abschnitt 5.2 durchgeführt.
Insgesamt wurden damit die Schritte der objektorientierten Analyse (OOA), die ObjektBeschreibungen, durchgeführt und in Form der aus dem Ausführungsmodell abgeleiteten
Gesamt-Architektur umgesetzt, so dass im folgenden Kapitel das objektorientierte Design
(OOD) der ReKlaMe-Architektur erfolgen kann.
86
6. Softwaretechnischer Entwurf des
ReDiCAt Systemes
Durch den Entwurf der Architektur und der darin enthaltenen Komponenten in Kapitel 5 wurde der Schritt der objektorientierten Analyse abgeschlossen. Es folgt das objektorientierte Design der Architektur. Dazu bedarf es der konkreten Konzeptionierung der Metadaten-Formate
zur Steuerung, Parametrisierung und zur Repräsentation der Daten der ReKlaMe-Architektur.
Dies umfasst die Metadaten, die beispielsweise die Basisklassifikator- oder die TrainingsdatenSelektion steuern oder die Parametrisierung der verwendeten Algorithmen übernehmen. Nach
der Konzeptionierung der Metadaten-Formate folgt das objektorientierte Design der Komponenten, aus denen die Architektur besteht. Die zu implementierende Software wird den Namen
ReDiCAt tragen. Das Akronym steht für ReKlaMe Distributed Classification Architecture.
Dieses Kapitel gliedert sich in vier Abschnitte: Abschnitt 6.1 befasst sich mit der Konzeptionierung und dem Design der Metadaten, die den Kontroll- und Datenfluss innerhalb der
Architektur umsetzen. Die verschiedenen Metadaten-Formate, die zur Durchführung der durch
die Architektur ermöglichten Analysen benötigt werden, werden der Reihe nach betrachtet und
konzeptioniert. Diese Betrachtungen erfolgen detailliert, um die Korrelation zwischen den in
Kapitel 4 dargestellten Formalisierungen der Analyse-Abläufe und den geplanten MetadatenFormaten in der Implementierung verdeutlichen zu können. Darauf folgend findet in Abschnitt
6.2 das objektorientierte Design der Komponenten statt, aus denen die Architektur besteht.
Die Komponenten werden unter Berücksichtigung ihrer Attribute und Methoden als Klassen
in Klassendiagrammen dargestellt. Eine detaillierte Beschreibung der Methoden und Attribute
der Komponentenklassen erfolgt nicht, hier sei auf das Javadoc verwiesen, welches unter
http://www.miaundpeppi.de/ReDiCAt/ einzusehen ist. Vielmehr erfolgt in diesem
Abschnitt die Beschreibung der Abbildung des Problemes auf die ausgewählte Architektur.
In Abschnitt 6.3 folgt schließlich die Beschreibung der Methodenaufrufe zur Durchführung
der Analyse-Abläufe in Form von Sequenz-Diagrammen. So befasst sich dieser Abschnitt mit
der Beschreibung des Zusammenspieles der verteilten Komponenten sowie der Kontroll- und
Datenflüsse zwischen den Komponenten. Abschließend wird in Abschnitt 6.4 eine Zusammenfassung der in diesem Kapitel erarbeiteten Ergebnisse gegeben.
6.1. Objektorientiertes Design der Metadatenformate
Die in Abbildung 5.5 dargestellte Architektur besteht aus verschiedenen Komponenten, die
miteinander kommunizieren müssen, um die abgebildeten Analyse-Abläufe umsetzen zu
können. Verschiedene Metadaten sind für die Steuerung der Selektion von Klassifikatoren
und Datensätzen vonnöten. Auch die Analyse-Algorithmen, die durch die Komponenten des
Analyse-Ablaufes umgesetzt werden, können durch Metadaten parametrisiert werden. Daher
werden diese im Folgenden im Rahmen des objektorientierten Designs entworfen und umgesetzt. Metadaten werden in dieser Art als abstrakte Datentypen (im Folgenden nur ADT
genannt) in Form von Java-Interfaces umgesetzt, zu denen jeweils eine prototypische Implementierung durchgeführt wird. Dazu werden die Metadaten in atomare Metadatenmengen aufgeteilt, für die dann jeweils ein Interface als abstrakter Datentyp entworfen wird. Aus
87
88
K APITEL 6 - S OFTWARETECHNISCHER E NTWURF DES R E D I CAT S YSTEMES
diesen Datentypen werden dann die für die einzelnen Komponenten benötigten MetadatenPakete zusammengesetzt. Daher folgt der weitere Verlauf dieses Abschnittes dieser Gliederung: zunächst werden in Abschnitt 6.1.1 die atomaren ADT-Interfaces und deren prototypische
Implementierungen vorgestellt. Anschließend werden in Abschnitt 6.1.2 die Interfaces sowie
deren prototypische Implementierungen zur Repräsentation der Kontrollflüsse der ArchitekturKomponenten aufgeführt, bevor in Abschnitt 6.1.3 die Interfaces und deren prototypische Implementierungen zur Repräsentation der parametrisierenden Metadatenmengen für die eingesetzten Analyse-Algorithmen entworfen werden. Für alle nachfolgenden Abschnitte gelte, dass
get<Attribut>()- und set<Attribut>()-Methoden nicht aufgeführt werden. Für jedes Attribut sei vorgegeben, dass eine get<Attribut>()- und eine set<Attribut>()Methode existiert. Im Falle der Interface-Beschreibungen werden die get<Attribut>()und set<Attribut>()-Methoden hingegen aufgeführt, da sie durch die Implementierungen umgesetzt werden müssen. Weiter gelte, dass alle Interfaces und Klassen, die ADT implementieren, vom Interface java.io.Serializable abgeleitet werden. Dies hat den Grund,
dass sie somit als serialisierte Objekte über Nachrichtenkanäle der EJB-Architektur kommuniziert werden können, um an verteilt vorliegende Komponenten übergeben werden zu können.
6.1.1. Interfaces und prototypische Implementierungen der abstrakten
Datentypen
Um die atomaren Daten-Entitäten beschreiben zu können, werden diese in Form von ADT
in Interfaces definiert. Zur Demonstration der Funktionalität der ReDiCAt-Architektur erfolgt
anschließend eine prototypische Implementierung dieser Interfaces. Folgend werden die zu
den identifizierten ADT entworfenen Interfaces und deren prototypische Implementierungen
im Rahmen eines Feinentwurfes dargestellt.
ClassificationTask (Interface)
Beschreibung Modelliert die Metadatenmenge zur Kontrolle des Ablaufes einer
Klassifikator-Anwendung.
Superinterfaces Task.java
Subinterfaces Implementierungen SimpleClassificationTask.java
Methoden Folgende Methoden müssen implementiert werden:
• ComponentAddress getAlgorithmComponentAddress(): gibt
die Adresse der Komponente zurück, die den Analyse-Algorithmus implementiert, der die Klassifikation durchführt.
• void setAlgorithmComponentAddress(ComponentAddress
algorithmComponentAddress): setzt die Adresse der Komponente,
die den Analyse-Algorithmus implementiert, der die Klassifikation durchführt,
auf den Parameter algorithmComponentAddress.
• ComponentAddress getBSKAddress(): gibt die Adresse der Komponente zurück, die die Basisklassifikator-Selektion durchführt.
• void setBSKAddress(ComponentAddress BSKAddress): setzt
die Adresse der Komponente, die die Basisklassifikator-Selektion durchführt,
auf den Parameter BSKAddress.
• ClassificationMetadata
getClassificationMetadataSet(): gibt die Metadaten
zurück, die die Komponente zur Klassifikator-Anwendung parametrisieren.
88
6.1 O BJEKTORIENTIERTES D ESIGN DER M ETADATENFORMATE
89
• void setClassificationMetadataSet(
ClassificationMetadata
classificationMetadataSet): setzt die Metadaten, die die Komponente zur Klassifikator-Anwendung parametrisieren, auf
den Parameter classificationMetadataSet.
• Classifier getClassifier(): gibt den bei der Klassifikation auf die
Instanzdaten anzuwendenden Klassifikator zurück.
• void setClassifier(Classifier classifier): setzt den bei
der Klassifikation auf die Instanzdaten anzuwendenden Klassifikator auf den
Parameter classifier.
• DBAGKMetadata getControlDBAGK(): gibt die Metadaten zur
Kontrolle der Komponente DBAGK der ReDiCAt-Architektur zur
Datenbankabfrage-Generierung aus Selection Graphs zurück.
• void setControlDBAGK(DBAGKMetadata controlDBAGK):
setzt die Metadatenmenge zur Kontrolle der Komponente DBAGK der
ReDiCAt-Architektur zur Generierung von Datenbank-Abfragen aus Selection Graphs auf den Parameter controlDBAGK.
• ComponentAddress getDSKAddress(): gibt die Adresse der Komponente zurück, die die Instanzdaten-Selektion durchführt.
• void setDSKAddress(ComponentAddress DSKAddress): setzt
die Adresse der Komponente, die die Instanzdaten-Selektion durchführt, auf
den Parameter DSKAddress.
• DSKMetadata getInstanceDataSet(): gibt die Metadaten zur Selektion der Instanzdatenmenge durch die DSK-Komponente zurück, die klassifiziert werden soll.
• void setInstanceDataSet(
DSKMetadata instanceDataSet): setzt die Metadaten zur
Selektion der Instanzdatenmenge, die klassifiziert werden soll, auf den Parameter instanceDataSet.
• java.lang.String getTaskName(): gibt eine String-Repräsentation des Namens des auszuführenden Analyse-Ablaufes zurück.
• void setTaskName(java.lang.String taskName): setzt die
String-Repräsentation des Namens des auszuführenden Analyse-Ablaufes auf
den Parameter taskName.
• VKMetadata getUtilisation(): gibt die Metadaten zurück, die die
weitere Verwendung der erzeugten ContentResource-Objekte beschreibt.
• void setUtilisation(VKMetadata utilisation): setzt die
Metadaten, die die weitere Verwendung der erzeugten ContentResourceObjekte beschreibt, auf den Parameter utilisation.
Classifier (Interface)
Beschreibung Modelliert einen Klassifikator.
Superinterfaces ContentResource.java
Subinterfaces Implementierungen SimpleClassifier.java
• DataSet getData(): gibt die prototypische Datenmenge, die einen
Klassifikator repräsentiert, zurück.
89
90
• void setData(DataSet data): setzt die prototypische Datenmenge,
die einen Klassifikator repräsentiert, auf den Parameter data.
• ClassifierLocation getLocation(): gibt die Beschreibung des
Ortes zurück, an dem ein Klassifikator gespeichert ist.
• void setLocation(ClassifierLocation location):
setzt
den Ort, an dem ein Klassifikator gespeichert ist, auf den Parameter
location.
• TimestampMetadata getTimestamps():
→ siehe ContentResource.
• void setTimestamps(TimestampMetadata timestamps):
ClassifierLocation (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung des Zugriffes auf
einen Klassifikator.
Superinterfaces ContentResourceLocation.java
Subinterfaces Implementierungen SimpleClassifierLocation.java
• ComponentAddress getDataSourceMD(): gibt die Adresse der
Komponente zurück, die die Datenquelle beinhaltet, in der der Klassifikator gespeichert ist.
• void setDataSourceMD(ComponentAddress dataSourceMD):
setzt die Adresse der Komponente, die die Datenquelle beinhaltet, die den
Klassifikator speichert, auf den Parameter dataSourceMD.
• java.lang.String getUserName(): gibt den Benutzernamen für
den Zugriff auf die Datenquelle an, in der der Klassifikator gespeichert ist.
• void setUserName(java.lang.String userName): setzt den
Benutzernamen für den Zugriff auf die Datenquelle, in der der Klassifikator
gespeichert ist, auf den Parameter userName.
• java.lang.String getUserPassword(): gibt das Passwort für den
Zugriff auf die Datenquelle an, in der der Klassifikator gespeichert ist.
• void setUserPassword(java.lang.String userPassword):
setzt das Passwort für den Zugriff auf die Datenquelle, in der der Klassifikator
gespeichert ist, auf den Parameter userPassword.
ComponentAddress (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Adressierung einer Komponente
der ReDiCAt-Architektur. Über diese Adresse wird es ermöglicht, eine Komponente in einem EJB-Container aufzufinden.
Superinterfaces Subinterfaces Implementierungen SimpleComponentAddress.java
• java.lang.String getComponentName(): gibt den Namen der
Komponente als String zurück.
• void setComponentName(java.lang.String componentName):
setzt den Namen der Komponente auf den Parameter componentName.
90
91
ContentResource (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung von inhaltlichen
Ressourcen innerhalb der ReDiCAt-Architektur. Zu diesen Ressourcen zählen
Klassifikatoren, Klassifikationsergebnisse und Datenmengen bestehend aus selektierten Datensätzen.
Superinterfaces
Subinterfaces Classifier.java, ResultDataSet.java, SelectedDataSet.java
Implementierungen SimpleClassifier.java, SimpleResultDataSet.java, SimpleSelectedDataSet.java
• TimestampMetadata getTimestamps(): gibt ein Objekt zur Speicherung von Transaktions- und Gültigkeitszeitstempeln zurück.
setzt ein Objekt von Transaktions- und Gültigkeitszeitstempeln auf den Parameter timestamps.
ContentResourceLocation (Interface)
eine Datenquelle/-senke. Um auf eine Datenquelle oder Datensenke zugreifen zu
können, wird die Adresse der Komponente, die die Datenquelle oder Datensenke
beherbergt, benötigt.
Superinterfaces Subinterfaces ClassifierLocation.java, ResultDataSetLocation.java
Implementierungen SimpleClassifierLocation.java, SimpleContentResourceLocation.java, SimpleResultDataSetLocation.java
• ComponentAddress getDataSourceMD(): gibt die Adresse der
Komponente, die die Datenquelle beinhaltet, zurück.
setzt die Adresse der Komponente, die die Datenquelle beinhaltet, auf den Parameter dataSourceMD.
DataSet (Interface)
Beschreibung Modelliert eine abstrakte Entität zur Speicherung von Daten jeglicher
Art.
Superinterfaces Subinterfaces Implementierungen SimpleDataSet.java
• java.util.Properties getDescription(): gibt die Beschreibungen eines Datensatzes in Form eines Properties-Objektes mit
Schlüssel-Wert-Paaren zurück. Diese kann genutzt werden, um eine
ContentResource wie einen Klassifikator oder ein Klassifikationsergebnis zu beschreiben und referenzierbar zu machen.
91
92
• void setDescription(java.util.Properties description):
setzt die Beschreibungen eines Datensatzes in Form eines Properties-Objektes
mit Schlüssel-Wert-Paaren auf den Parameter description. Diese kann
genutzt werden, um eine ContentResource wie einen Klassifikator oder
ein Klassifikationsergebnis zu beschreiben und referenzierbar zu machen.
InductionTask (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Kontrolle des Ablaufes einer
Klassifikator-Induktion.
Subinterfaces Implementierungen SimpleInductionTask.java
die Adresse der Komponente zurück, die den Analyse-Algorithmus implementiert, der die Klassifikator-Induktion durchführt.
algorithmComponentAddress): setzt die Adresse der Komponente,
die den Analyse-Algorithmus implementiert, der die Klassifikator-Induktion
durchführt, auf den Parameter algorithmComponentAddress.
• java.util.Vector getBSKAddresses(): gibt die Adressen der
Komponenten zurück, die die Basisklassifikator-Selektionen durchführen. Die
selektierten Basisklassifikatoren werden für den Analyseschritt der inkrementellen Klassifikator-Induktion oder für den Analyseschritt des Meta-Lernens
benötigt. Das Vector-Objekt beinhaltet ComponentAddress-Objekte zur
Beschreibung der Komponenten, die die Basisklassifikatoren beinhalten.
• void setBSKAddresses(java.util.Vector BSKAddresses):
setzt die Adressen der Komponenten, die die Basisklassifikator-Selektion
durchführen, auf den Parameter BSKAddress. Die selektierten Basisklassifikatoren werden für den Analyseschritt der inkrementellen KlassifikatorInduktion oder für den Analyseschritt des Meta-Lernens benötigt. Das
Vector-Objekt beinhaltet ComponentAddress-Objekte zur Beschreibung der Komponenten, die die Basisklassifikatoren beinhalten.
• Vector getClassifierSet(): gibt die Metadaten zur Selektion
der bei der inkrementellen Klassifikator-Induktion oder beim Meta-Lernen
benötigten Klassifikatoren zurück.
• void setClassifierSet(
java.util.Vector classifierSet): setzt die Metadaten zur Selektion der bei der inkrementellen Klassifikator-Induktion
oder beim Meta-Lernen benötigten Klassifikatoren auf den Parameter
classifierSet.
• ComponentAddress getDSKAddress(): gibt die Adresse der Komponente zurück, die die Trainingsdaten-Selektion durchführt.
• void setDSKAddress(ComponentAddress DSKAddress): setzt
die Adresse der Komponente, die die Trainingsdaten-Selektion durchführt, auf
den Parameter DSKAddress.
• InductionMetadata getInductionMetadataSet(): gibt die
Metadaten zurück, die die Komponente zur Klassifikator-Induktion parametrisieren.
92
93
• void setInductionMetadataSet(
InductionMetadata inductionMetadataSet): setzt
die Metadaten, die die Komponente zur Klassifikator-Induktion parametrisieren, auf den Parameter inductionMetadataSet.
• DSKMetadata getTrainingsDataSet(): gibt die Metadaten zur Selektion der Trainingsdaten, auf deren Basis der Klassifikator induziert werden
soll, zurück.
• void setTrainingsDataSet(
DSKMetadata trainingsDataSet): setzt die Metadaten
zur Selektion der Trainingsdaten, auf deren Basis der Klassifikator induziert
werden soll, auf den Parameter trainingsDataSet.
• VKMetadata getUtilisation(): gibt das Objekt zurück, das die weitere Verwendung der erzeugten ContentResource-Objekte beschreibt.
• void setUtilisation(VKMetadata utilisation): setzt das
Objekt, das die weitere Verwendung der erzeugten ContentResource-Objekte
beschreibt, auf den Parameter utilisation.
MaintenanceTask (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Kontrolle des Ablaufes einer
Klassifikator-Wartung
Subinterfaces Implementierungen SimpleMaintenanceTask.java
die Adresse der Komponente zurück, die den Analyse-Algorithmus implementiert, der die Klassifikator-Induktion des neu zu erstellenden Klassifikators,
der gewartet wurde, durchführt.
algorithmComponentAddress): setzt die Adresse der Komponente, die den Analyse-Algorithmus implementiert, der die KlassifikatorInduktion des zu wartenden Klassifikators durchführt, auf den Parameter
algorithmComponentAddress.
• java.util.Vector getBSKAddresses(): gibt die Adressen der
Komponenten zurück, die die Basisklassifikator-Selektionen durchführen. Die
selektierten Basisklassifikatoren werden für den Analyseschritt der inkrementellen Klassifikator-Induktion benötigt. Das Vector-Objekt beinhaltet
ComponentAddress-Objekte zur Beschreibung der Komponenten, die die
Basisklassifikatoren beinhalten. Der zu wartende Klassifikator wird nach dessen Invalidierung neu induziert.
• void setBSKAddresses(java.util.Vector BSKAddresses):
setzt die Adressen der Komponenten, die die Basisklassifikator-Selektion
93
94
•
•
•
•
•
•
•
•
•
•
durchführen, auf den Parameter BSKAddress. Die selektierten Basisklassifikatoren werden für den Analyseschritt der inkrementellen KlassifikatorInduktion benötigt. Das Vector-Objekt beinhaltet ComponentAddressObjekte zur Beschreibung der Komponenten, die die Basisklassifikatoren
beinhalten. Der zu wartende Klassifikator wird nach dessen Invalidierung neu
induziert.
Vector getClassifierSet(): gibt die Metadaten zur Selektion der
bei der inkrementellen Klassifikator-Induktion benötigten Klassifikatoren
zurück.
void setClassifierSet(
java.util.Vector classifierSet): setzt die Metadaten
zur Selektion der bei der inkrementellen Klassifikator-Induktion benötigten
Klassifikatoren auf den Parameter classifierSet.
ClassifierLocation
getClassifierToBeMaintainedLocation(): gibt die
Metadaten zum Zugriff auf den Klassifikator zurück, der gewartet werden soll.
Die Wartung umfasst den Schritt der Invalidierung des alten Klassifikators sowie die Induktion eines neuen Klassifikators auf Basis des alten.
void setClassifierToBeMaintainedLocation(
ClassifierLocation cLocation): setzt die Metadaten
zum Zugriff auf den Klassifikator, der gewartet werden soll, auf den Parameter cLocation. Die Wartung umfasst den Schritt der Invalidierung des
alten Klassifikators sowie die Induktion eines neuen Klassifikators auf Basis
des alten.
ComponentAddress getDSKAddress(): gibt die Adresse der Komponente zurück, die die Trainingsdaten-Selektion zur Klassifikator-Induktion
durchführt.
void setDSKAddress(ComponentAddress DSKAddress): setzt
die Adresse der Komponente, die die Trainingsdaten-Selektion zur
Klassifikator-Induktion durchführt, auf den Parameter DSKAddress.
ComponentAddress getIVKAddress(): gibt die Adresse der Komponente zurück, die die Invalidierung des zu wartenden Klassifikators
durchführt. Die Invalidierung erfolgt durch Setzen eines Zeitstempels für
das Attribut des Transaktionszeitendes.
void setIVKAddress(ComponentAddress IVKAddress): setzt
die Adresse der Komponente, die die Invalidierung des zu wartenden Klassifikators durchführt, auf den Parameter DSKAddress. Die Invalidierung erfolgt
durch Setzen eines Zeitstempels für das Attribut des Transaktionszeitendes.
IVKMetadata getIVKMetadata(): gibt die Metadaten zur Parametrisierung der Invalidierungskomponente zurück. Diese Metadaten umfassen die
Adresse der globalen Uhr sowie die Adresse der Datenquelle, in die der zu invalidierende Klassifikator gespeichert werden soll und die Adresse der Komponente, die die Bestätigungsnachricht der erfolgreichen Auslieferung des invalidierten Klassifikators erhalten soll.
void setIVKMetadata(IVKMetadata metadata):setzt die Metadaten zur Parametrisierung der Invalidierungskomponente auf den Parameter
metadata. Diese Metadaten umfassen die Adresse der globalen Uhr sowie
die Adresse der Datenquelle, in die der zu invalidierende Klassifikator gespeichert werden soll und die Adresse der Komponente, die die Bestätigungsnachricht der erfolgreichen Auslieferung des invalidierten Klassifikators erhalten
soll.
94
95
• MaintenanceMetadata getMaintenanceMetadataSet(): gibt
die Metadaten zurück, die die Komponente zur Klassifikator-Induktion parametrisieren.
• void setMaintenanceMetadataSet(
MaintenanceMetadata maintenanceMetadataSet):
setzt die Metadaten, die die Komponente zur Klassifikator-Induktion parametrisieren, auf den Parameter maintenanceMetadataSet.
• DSKMetadata getTrainingsDataSet(): gibt die Metadaten zur Selektion der Trainingsdaten, auf deren Basis der Klassifikator neu induziert werden soll, zurück.
• void setTrainingsDataSet(
DSKMetadata trainingsDataSet): setzt die Metadaten
zur Selektion der Trainingsdaten, auf deren Basis der Klassifikator neu induziert werden soll, auf den Parameter trainingsDataSet.
ParameterSet (Interface)
Beschreibung Modelliert eine Menge von Parametern, anhand derer ein Algorithmus
parametrisiert werden kann, der von einer Komponente der ReDiCAt-Architektur
umgesetzt wird.
Superinterfaces Subinterfaces Implementierungen SimpleParameterSet.java
• java.util.Properties getParameters(): gibt ein Objekt vom
Typ java.util.Properties zurück, welches die Parameter zur Parametrisierung eines Algorithmus beinhaltet, den eine Komponente der ReDiCAtArchitektur umsetzt. Diese liegen in Form von Schlüssel-Wert-Paaren vor.
• void setParameters(java.util.Properties params): setzt
das java.util.Properties-Objekt, welches die Parameter zur Parametrisierung eines Algorithmus beinhaltet, den eine Komponente der ReDiCAtArchitektur umsetzt, auf den Parameter params.
QueryMetadata (Interface)
Beschreibung Modelliert eine Datenbankabfrage zur Selektion einer Datenmenge aus
einer Datenquelle.
Superinterfaces Subinterfaces Implementierungen SimpleQueryMetadata.java
95
96
• java.lang.String getQueryString(): gibt einen String zurück,
der die Datenbankabfrage enthält, die ausgeführt werden soll.
• void setQueryString(java.lang.String queryString):
setzt den String, der die Datenbankabfrage enthält, die ausgeführt werden
soll, auf den Parameter queryString.
ResultDataSet (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung eines Ergebnisdatensatzes einer Klassifikator-Anwendung.
Subinterfaces Implementierungen SimpleResultDataSet.java
• ClassifierLocation getClassifierLocation(): gibt die Metadaten zum Zugriff auf den Klassifikator zurück, auf dessen Basis die Ergebnisdatenmenge der Klassifikation erzeugt wurde.
• void setClassifierLocation(
ClassifierLocation classifierLocation):
setzt
die Metadaten zum Zugriff auf den Klassifikator, der die Basis der
Ergebnisdatenmenge der Klassifikation darstellt, auf den Parameter
classifierLocation.
• DataSet getData(): gibt die prototypische Datenmenge zurück, die ein
Klassifikationsergebnis repräsentiert.
die ein Klassifikationsergebnis repräsentiert, auf den Parameter data.
• ResultDataSetLocation getDataLocation(): gibt die Beschreibung des Ortes an, an dem die Ergebnismenge der Klassifikation gespeichert wurde.
• void setDataLocation(
ResultDataSetLocation dataLocation): setzt die Beschreibung des Ortes, an dem die Ergebnismenge der Klassifikation gespeichert wurde, auf den Parameter dataLocation.
ResultDataSetLocation (Interface)
einen Ergebnisdatensatz einer Klassifikator-Anwendung.
Superinterfaces ContentResourceLocation.java
Subinterfaces Implementierungen SimpleResultDataSetLocation.java
• ComponentAddress getDataSourceMD(): gibt die Metadaten zum
Zugriff auf die Datenquelle zurück, in der die Ergebnisdatenmenge der Klassifikation gespeichert wurde.
96
97
setzt die Metadaten zum Zugriff auf die Datenquelle, in der die Ergebnisdatenmenge der Klassifikation gespeichert wurde, auf den Parameter
dataSourceMD.
• java.lang.String getUserName(): gibt eine String-Repräsentation des Benutzernamens zurück, der benötigt wird, um die Ergebnisdatenmenge der Klassifikation aus der Datenquelle, in der sie gespeichert ist, auszulesen.
• void setUserName(java.lang.String userName): setzt die
String-Repräsentation des Benutzernamens, der benötigt wird, um die Ergebnisdatenmenge der Klassifikation aus der Datenquelle, in der sie gespeichert
ist, auszulesen, auf den Parameter userName.
• java.lang.String getUserPasswd(): gibt eine String-Repräsentation des Passwortes zurück, das benötigt wird, um die Ergebnisdatenmenge
der Klassifikation aus der Datenquelle, in der sie gespeichert ist, auszulesen.
• void setUserPasswd(java.lang.String userPasswd): setzt
die String-Repräsentation des Passwortes, das benötigt wird, um die Ergebnisdatenmenge der Klassifikation aus der Datenquelle, in der sie gespeichert
ist, auszulesen, auf den Parameter userPasswd.
SelectedDataSet (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung einer Menge von
Daten, die aus einer Datenquelle selektiert wurden. Dies können Trainingsdaten
oder Instanzdaten sein.
Subinterfaces Implementierungen SimpleSelectedDataSet.java
• DataSet getData(): gibt die prototypische Datenmenge zurück, die eine selektierte Datenmenge repräsentiert.
die eine selektierte Datenmenge repräsentiert, auf den Parameter data.
• ContentResourceLocation getLocation(): gibt die Metadaten
zum Zugriff auf die Datenquelle zurück, aus der die selektierten Daten stammen.
• void setLocation(ContentResourceLocation location):
setzt die Metadaten zum Zugriff auf die Datenquelle, aus der die selektierten
Daten stammen, auf den Parameter location.
Task (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung eines AnalyseAblaufes, der von der ReDiCAt-Architektur durchgeführt werden kann.
Superinterfaces Subinterfaces ClassificationTask.java, InductionTask.java, MaintenanceTask.java
97
98
Implementierungen SimpleClassificationTask.java, SimpleInductionTask.java, SimpleMaintenanceTask.java
• java.lang.String getTaskName(): gibt die String-Repräsentation
des Namens des Tasks zurück, der von der ReDiCAt-Architektur auszuführen
ist.
String-Repräsentation des Namens des auszuführenden Analyse-Ablaufes, der
von der ReDiCAt-Architektur auszuführen ist, auf den Parameter taskName.
TimestampMetadata (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Beschreibung einer Menge von
Zeitstempeln zur Speicherung von Transaktions- und Gültigkeitszeiten. Bei der
Zeitstempelung findet die Intervall-Semantik Anwendung. So werden Zeitstempel
jeweils für das Intervall der Gültigkeit eines Datensatzes in der realen Welt sowie
für die Gültigkeit eines Datensatzes im System vergeben. Das Intervall weist einen
Anfangs- und einen Endpunkt für beide Gültigkeitsdomänen auf.
Superinterfaces Subinterfaces Implementierungen SimpleTimestampMetadata.java
• java.security.Timestamp getTtb(): gibt den Zeitstempel des
Anfangs der Transaktionszeit zurück. Dieser wird gesetzt, wenn ein Datensatz
erstmalig gespeichert wird.
• void setTtb(java.security.Timestamp ttb): setzt den Zeitstempel des Anfanges der Transaktionszeit auf den Parameter ttb.
• java.security.Timestamp getTte(): gibt den Zeitstempel des
Endes der Transaktionszeit zurück. Dieser wird gesetzt, wenn ein Datensatz
gelöscht werden soll. Anstelle der Löschung erfolgt hier eine Markierung als
gelöscht. Somit ist temporale Versionierung möglich.
• void setTte(java.security.Timestamp tte): setzt den Zeitstempel des Endes der Transaktionszeit auf den Parameter tte.
• java.security.Timestamp getVtb(): gibt den Zeitstempel des
Anfanges der Gültigkeitszeit zurück. Dieser steht für den Zeitpunkt, ab dem
ein Datensatz in der realen Welt als gültig gilt.
• void setVtb(java.security.Timestamp vtb): setzt den Zeitstempel des Anfanges der Gültigkeitszeit auf den Parameter vtb.
• java.security.Timestamp getVte(): gibt den Zeitstempel des
Endes der Gültigkeitszeit zurück. Dieser steht für den Zeitpunkt, ab dem ein
Datensatz in der realen Welt als ungültig markiert wird.
• void setVte(java.security.Timestamp vte): setzt den Zeitstempel des Endes der Gültigkeitszeit auf den Parameter vte.
98
99
Die Interfaces zur Umsetzung der ADT, ihre get<Attribut>- und set<Attribut>Methoden sowie die Assoziationen zwischen den einzelnen Interfaces sind in Abbildung 6.1 in
Form eines Klassendiagrammes aufgeführt.
<<interface>>
<<interface>>
ContentResourceLocation
ComponentAddress
<<use>>
getDataSourceMD()
getComponentName()
setDataSourceMD()
setComponentName()
<<use>>
<<interface>>
ResultDataSetLocation
<<interface>>
<<interface>>
ClassifierLocation
TimestampMetadata
getDataSourceMD()
getTtb()
setDataSourceMD()
setTtb()
getUserName()
getTte()
setUserName()
setTte()
getUserPassword()
getVtb()
setUserPassword()
setVtb()
<<interface>>
ContentResource
getDataSourceMD()
<<use>>
setDataSourceMD()
getTimestamps()
getUserName()
setTimestamps()
setUserName()
getUserPasswd()
<<use>>
setUserPasswd()
getVte()
setVte()
<<interface>>
<<interface>>
<<interface>>
ResultDataSet
SelectedDataSet
Classifier
getClassifierLocation()
getData()
getData()
setClassifierLocation()
setData()
setData()
getData()
getLocation()
getLocation()
setData()
setLocation()
setLocation()
<<use>>
<<use>>
getDataLocation()
setDataLocation()
<<interface>>
<<use>>
Task
<<use>>
<<interface>>
DataSet
getTaskName()
<<use>>
setTaskName()
getUtilisation()
getDescription()
setUtilisation()
setDescription()
<<interface>>
QueryMetadata
getQueryString()
<<interface>>
<<interface>>
<<interface>>
setQueryString()
ClassificationTask
InductionTask
MaintenanceTask
<<interface>>
ParameterSet
getClassifier()
getClassifierSet()
getClassifierSet()
setClassifier()
setClassifierSet()
setClassifierSet()
getDSKAddress()
getTaskName()
getTaskName()
setDSKAddress()
setTaskName()
setTaskName()
getParameters()
getBSKAddress()
getDSKAddress()
getDSKAddress()
setParameters()
setBSKAddress()
setDSKAddress()
setDSKAddress()
getAlgorithmComponentAddress()
getBSKAddresses()
getBSKAddresses()
setAlgorithmComponentAddress()
setBSKAddresses()
setBSKAddresses()
getInstanceDataSet()
setInstanceDataSet()
getTaskName()
getTrainingsDataSet()
getIVKAddress()
setTaskName()
setTrainingsDataSet()
setIVKAddress()
getControlDBAGK()
getInductionMetadataSet()
setControlDBAGK()
setInductionMetadataSet()
getClassificationMetadataSet()
getUtilisation()
getMaintenanceMetadataSet()
setClassificationMetadataSet()
setMaintenanceMetadataSet()
getUtilisation()
getUtilisation()
getIVKMetadata()
setIVKMetadata()
getClassifierToBeMaintainedLocation()
setClassifierToBeMaintainedLocation()
Abbildung 6.1.: Klassendiagramm der Interfaces zur Abbildung der ADT
SimpleClassificationTask (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces
ClassificationTask dar und dient dem Zwecke der Demonstration der
Funktionsfähigkeit der ReDiCAt-Architektur. Alle Metadaten, die zur Konfiguration der Komponenten benötigt werden, die an einem Klassifikations-Ablauf beteiligt sind, sowie zusätzliche Informationen über die Adressen der zu verwendenden Komponenten sowie zu den Kontroll- und Datenflüssen werden in diesem Objekt gespeichert. Es beinhaltet alle Informationen, die die ReDiCAt-Architektur
benötigt, um den Analyse-Ablauf der Klassifikation durchführen zu können.
Implementierte Interfaces ClassificationTask.java, Task.java
Attribute Folgende Attribute wurden implementiert:
• java.lang.String taskName:
zuführenden Analyse-Ablaufes.
String-Repräsentation
99
des
aus-
100
• ComponentAddress DSKAddress: Adresse der Komponente, die die
Selektion der Instanzdaten durchführt.
• ComponentAddress BSKAddress: Adresse der Komponente, die die
Selektion des Basisklassifikators durchführt, der die Grundlage des Ablaufes
der Klassifikation darstellt.
• ComponentAddress algorithmComponentAddress: Adresse der
Komponente, die den Klassifikations-Algorithmus implementiert und die
Klassifikation auf Basis des selektierten Klassifikators und der selektierten Instanzdaten durchführt.
• BSKMetadata classifier: Metadaten zur Selektion des Klassifikators,
auf Basis dessen die Klassifikation durchgeführt werden soll.
• ClassificationMetadata classificationMetadata: Metadaten zur Parametrisierung des Klassifikations-Algorithmus.
• DBAGKMetadata controlDBAGK: Metadaten zur Kontrolle der Komponente DBAGK. Im Falle der Klassifikation durch Selection Graph-Ableitung
generiert diese Komponente eine Menge von Datenbankabfragen aus einer
Menge von Selection Graphs, die von der Komponente SGAK aus einem Klassifikator generiert wurden.
• VKMetadata utilisation: die Metadaten, die die weitere Verwendung
der erzeugten ContentResource-Objekte festlegen. Diese Metadaten bestehen zum Einen aus einem java.util.String-Objekt, welches die Verwertung des erzeugten ContentResource-Objektes vorgibt. Hier sind folgende Werte erlaubt:
– store zum Speichern des erzeugten ContentResource-Objektes
– visualize zur visuellen Ausgabe des erzeugten ContentResourceObjektes gegenüber einem Benutzer
– both zur Speicherung und visuellen Ausgabe des erzeugten
ContentResource-Objektes gegenüber einem Benutzer
Zum Anderen bestehen die Metadaten aus einem ContentResourceObjekt, welches die Datensenke spezifiziert, in die das erzeugte
ContentResource-Objekt gespeichert werden soll, und die Daten beinhaltet, die zum Zugriff auf diese Datensenke benötigt werden.
Konstruktoren Ein Konstruktor wird implementiert:
1
2
3
4
5
6
7
8
9
10
public SimpleClassificationTask(
java.lang.String taskName,
ComponentAddress BSKAddress,
ComponentAddress DSKAddress,
ComponentAddress algorithmComponentAddress,
DSKMetadata instanceDataSet,
BSKMetadata classifier,
VKMetadata utilisation,
ClassificationMetadata classificationMetadataSet,
DBAGKMetadata controlDBAGK)
Listing 6.1: Konstruktor SimpleClassificationTask.java
Methoden Es werden get<Attribut>() und set<Attribut>()-Methoden für
jedes vorhandene Attribut implementiert.
100
101
SimpleClassifier (Class)
Classifier dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Da die Implementierung der Architektur lediglich
prototypisch durchgeführt wird, wird auch nur ein prototypischer Klassifikator
benötigt. Diese Implementierung des Classifier-Interfaces besitzt keine direkt auf
einen Klassifikator übertragbare Semantik, sondern soll lediglich als prototypisches Objekt dazu dienen, die Funktionsfähigkeit der Infrastruktur der ReDiCAtArchitektur zu demonstrieren.
Implementierte Interfaces Classifier.java, ContentResource.java
• TimestampMetadata timestamps: Objekt zur Speicherung von
Transaktions- und Gültigkeitszeitstempeln. Über die Zeitstempel wird angegeben, ob ein Klassifikator als gültig in der realen Welt oder im System
geführt wird.
• DataSet data: die prototypische Datenmenge, die einen Klassifikator repräsentiert. Diese trägt keinerlei Semantik, sondern soll ein Platzhalter für potentielle Datenformate darstellen, die einen Klassifikator beschreiben können.
• ClassifierLocation location: die Metadaten, die zum Zugriff auf
einen Klassifikator benötigt werden. Dazu zählen der Ort der Komponente, die
die Datenquelle beherbergt, die den Klassifikator speichert, sowie Benutzername und Passwort zum Zugriff auf diese Datenquelle.
1
2
3
4
public SimpleClassifier(
TimestampMetadata timestamps,
DataSet data,
ClassifierLocation location)
Listing 6.2: Konstruktor SimpleClassifier.java
SimpleClassifierLocation (Class)
ClassifierLocation dar und dient dem Zwecke der Demonstration der
Funktionsfähigkeit der ReDiCAt-Architektur. In dieser Klasse werden die Metadaten zusammengefasst, die zum Zugriff auf einen Klassifikator benötigt werden.
Dazu zählen der Ort der Komponente, die die Datenquelle beherbergt, die den Klassifikator speichert, sowie Benutzername und Passwort zum Zugriff auf diese Datenquelle. Bei dieser Klasse handelt es sich um eine prototypische Implementierung.
Implementierte Interfaces ClassifierLocation.java, ContentResourceLocation.java
• ComponentAddress dataSourceMD: die Adresse der Komponente, die
die Datenquelle beinhaltet, in der ein Klassifikator gespeichert ist.
• java.lang.String userName: der Benutzername für den Zugriff auf
die Datenquelle, in der ein Klassifikator gespeichert ist.
• java.lang.String userPassword: das Passwort für den Zugriff auf
die Datenquelle, in der ein Klassifikator gespeichert ist.
101
102
1
2
3
4
public SimpleClassifierLocation(
ComponentAddress dataSourceMD,
java.lang.String userName,
java.lang.String userPassword)
Listing 6.3: Konstruktor SimpleClassifierLocation.java
SimpleComponentAddress (Class)
ComponentAddress dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Sie beinhaltet den Namen einer Komponente in Form einer String-Repräsentation. Dieser Name dient der Lokalisierung
der Komponente innerhalb der ReDiCAt-Architektur.
Implementierte Interfaces ComponentAddress
• java.lang.String componentName: der Name der Komponente als
String-Repräsentation.
1
2
public SimpleComponentAddress(
java.lang.String componentName)
Listing 6.4: Konstruktor SimpleComponentAddress.java
SimpleContentResourceLocation (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces ContentResourceLocation dar und dient dem Zwecke der
Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Sie wird
verwendet, um die Metadaten zusammenzufassen, die benötigt werden,
um auf ein ContentResource-Objekt zugreifen zu können. Diese
Metadaten beinhalten, analog zu SimpleClassifierLocation und
SimpleResultDataSetLocation, den Ort der Komponente, die die Datenquelle beherbergt, die den Klassifikator speichert, sowie den Benutzernamen
und das Passwort zum Zugriff auf diese Datenquelle. Es handelt sich bei dieser
Implementation des ContentResource-Interfaces um eine generisch zu verwendende Klasse, die in den Fällen genutzt werden soll, in denen der Typ des
ContentResource-Objektes nicht bekannt ist.
Implementierte Interfaces ContentResourceLocation.java
die Datenquelle beinhaltet, in der sich die ContentResource befindet.
• java.lang.String userName: der Benutzername, der zum Zugriff auf
die Datenquelle benötigt wird, in der sich die ContentResource befindet.
102
103
• java.lang.String userPasswd: das Passwort, das zum Zugriff auf
die Datenquelle benötigt wird, in der sich die ContentResource befindet.
1
2
3
4
public SimpleContentResourceLocation(
java.lang.String userPasswd)
Listing 6.5: Konstruktor SimpleContentResourceLocation.java
SimpleDataSet (Class)
DataSet dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit
der ReDiCAt-Architektur. Sie stellt eine prototypische Datenmenge dar, die analog
zur Klasse SimpleClassifier keine direkte Semantik aufweist, sondern zur
Demonstration der Funktionsfähigkeit der Infrastruktur der ReDiCAt-Architektur
dient. Sie wird beispielsweise verwendet, um die Datenmengen, die einen Klassifikator oder ein Klassifikationsergebnis beinhalten sollen, prototypisch umzusetzen.
Implementierte Interfaces DataSet.java
• java.util.Properties description: ein Properties-Objekt zur
Speicherung von Schlüssel-Wert-Paaren, die zur Beschreibung eines
ContentResource-Objektes genutzt werden können.
1
2
public SimpleDataSet(
java.util.Properties description)
Listing 6.6: Konstruktor SimpleDataSet.java
SimpleInductionTask (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces InductionTask dar und dient dem Zwecke der Demonstration
der Funktionsfähigkeit der ReDiCAt-Architektur. Analog zu den Klassen
SimpleClassificationTask und SimpleMaintenanceTask werden
in dieser Klasse alle Metadaten, die zur Konfiguration der Komponenten benötigt
werden, die an einem Klassifikator-Induktions-Ablauf beteiligt sind, gespeichert.
Zusätzliche Informationen über die Adressen der zu verwendenden Komponenten sowie zu den Kontroll- und Datenflüssen werden ebenfalls in dieser Klasse
gespeichert. Somit beinhaltet ein Objekt dieser Klasse alle Informationen, die
zur Durchführung einer Klassifikator-Induktion durch die ReDiCAt-Architektur
benötigt werden.
Implementierte Interfaces InductionTask.java, Task.java
103
104
• java.lang.String taskName: die String-Repräsentation des Namens
des durchzuführenden Analyse-Schrittes. Hier sind folgende Werte erlaubt:
– ci für die einfache Induktion eines Klassifikators. In diesem Fall werden
keine Basisklassifikatoren bei der Induktion berücksichtigt.
– ici für die inkrementelle Induktion eines Klassifikators. Hier fließen neben den Trainingsdaten noch Basisklassifikatoren in die Induktion mit ein.
– ml für einen Meta-Lern-Analyse-Ablauf. Dieser kombiniert aus verschiedenen Basisklassifikatoren ein neues globales Modell.
• ComponentAddress DSKAddress: die Adresse der Komponente, die
die Selektion der Instanzdaten durchführt, auf Basis derer eine KlassifikatorInduktion durchgeführt wird.
• java.util.Vector BSKAddresses: ein Vector-Objekt, welches
die Adressen der Komponenten beinhaltet, die die Selektion von BasisKlassifikatoren durchführen, die für eine inkrementelle KlassifikatorInduktion oder für einen Meta-Lern-Vorgang benötigt werden. Da mehrere Basisklassifikatoren in die zuvor genannten Analyse-Abläufe eingehen
können, und da diese verteilt an verschiedenen Orten vorliegen können, wird
hier ein java.util.Vector-Objekt genutzt.
• ComponentAddress algorithmComponentAddress: die Adresse
der Komponente, die den Algorithmus implementiert, der die KlassifikatorInduktion oder den Meta-Lern-Vorgang durchführt.
• DSKMetadata trainingsDataSet: die Metadaten, die zur Selektion
der Trainingsdaten benötigt werden, auf Basis derer ein Klassifikator induziert
werden soll.
• java.util.Vector classifierSet: ein jave.util.VectorObjekt, welches die Metadaten zur Selektion der Klassifikatoren beinhaltet,
die für eine inkrementelle Klassifikator-Induktion oder einen Meta-LernAnalyse-Ablauf benötigt werden.
der erzeugten ContentResource-Objekte festlegen. Diese Metadaten bestehen zum Einen aus einem java.util.String-Objekt, welches die Verwertung des erzeugten ContentResource-Objektes vorgibt. Hier sind folgende Werte erlaubt:
1
2
3
4
5
6
7
public SimpleInductionTask(
java.util.Vector BSKAddresses,
DSKMetadata trainingsDataSet,
java.util.Vector classifierSet,
104
8
9
105
InductionMetadata inductionMetadataSet)
Listing 6.7: Konstruktor SimpleInductionTask.java
SimpleMaintenanceTask (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces MaintenanceTask dar und dient dem Zwecke der Demonstration
der Funktionsfähigkeit der ReDiCAt-Architektur. Analog zu den Klassen
SimpleClassificationTask und SimpleInductionTask beinhaltet
diese Klasse die für den Analyse-Ablauf der Klassifikator-Wartung notwendigen
Metadaten. Zu diesen Metadaten zählen auch hier die Metadaten zur Konfiguration
der am Analyse-Ablauf beteiligten Komponenten, zusätzliche Informationen über
die Adressen der beteiligten Komponenten sowie Informationen über die Kontrollund Datenflüsse. Somit beinhaltet ein Objekt dieser Klasse alle Informationen, die
zur Durchführung einer Klassifikator-Wartung benötigt werden.
Implementierte Interfaces MaintenanceTask.java, Task.java
• java.lang.String taskName: die String-Repräsentation des Namens
des durchzuführenden Analyse-Schrittes. Im Falle der Klassifikator-Wartung
ist hier ausschließlich folgender Wert erlaubt:
– maintenance für die Wartung eines Klassifikators
• ComponentAddress DSKAddress: die Adresse der Komponente, die
die Selektion der Instanzdaten durchführt, die für die Neugenerierung eines
Klassifikators benötigt werden.
• java.util.Vector BSKAddresses: ein Vector-Objekt, welches die
Adressen der Komponenten beinhaltet, die die Selektion der Basisklassifikatoren durchführen, die im Falle einer inkrementellen Neugenerierung des zu
wartenden Klassifikators benötigt werden.
• ComponentAddress algorithmComponentAddress: die Adresse
der Komponente, die die Neugenerierung des zu wartenden Klassifikators
durchführt.
• ComponentAddress IVKAddress: die Adresse der Komponente, die
die Invalidierung des zu wartenden Klassifikators durchführt.
• DSKMetadata trainingsDataSet: die Metadaten, die zur Selektion
der Trainingsdaten benötigt werden, die bei der Neugenerierung des zu wartenden Klassifikators erforderlich sind.
• java.util.Vector classifierSet: ein Vector-Objekt, welches
die Metadaten beinhaltet, die zur Selektion der (im Falle der inkrementellen
Neugenerierung des zu wartenden Klassifikators benötigten) Basisklassifikatoren benötigt werden.
• MaintenanceMetadata maintenanceMetadataSet: die Metadaten, die zur Parametrisierung der Komponente benötigt werden, die im Falle
der Klassifikator-Wartung die Neugenerierung des zu wartenden Klassifikators
durchführt.
der erzeugten ContentResource-Objekte festlegen. Diese Metadaten be-
105
106
stehen zum Einen aus einem java.util.String-Objekt, welches die Verwertung des erzeugten ContentResource-Objektes vorgibt. Hier sind folgende Werte erlaubt:
• IVKMetadata IVKMetadata: die Metadaten, die zur Steuerung der
Invalidierungs-Komponente benötigt werden. Diese bestehen aus der Adresse
der globalen Uhr, der Adresse der Komponente, die im Falle der erfolgreichen
Invalidierung eines Klassifikators zu benachrichtigen ist, sowie den Metadaten, die zur Selektion des zu invalidierenden Klassifikators benötigt werden.
1
2
3
4
5
6
7
8
9
10
11
12
public SimpleMaintenanceTask(
java.util.Vector BSKAddresses,
ComponentAddress IVKAddress,
DSKMetadata trainingsDataSet,
java.util.Vector classifierSet,
MaintenanceMetadata analysisMetadataSet,
IVKMetadata IVKMetadata,
ClassifierLocation classifierToBeMaintainedLocation)
Listing 6.8: Konstruktor SimpleMaintenanceTask.java
SimpleParameterSet (Class)
ParameterSet dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Sie dient als prototypische Datenmenge, die die Parameter repräsentiert, die einer Komponente der ReDiCAtArchitektur übergeben werden, die einen Analyse-Algorithmus implementiert. Diese Klasse besitzt keine direkte Semantik, sondern stellt durch das
java.util.Properties-Objekt eine Möglichkeit dar, Semantik in Form
von Schlüssel-Wert-Paaren zu transportieren.
Implementierte Interfaces ParameterSet.java
• java.util.Properties parameters: ein Properties-Objekt,
welches die Parameter zur Parametrisierung eines Algorithmus beinhaltet, den
eine Komponente der ReDiCAt-Architektur umsetzt. Die Parameter werden
in Form von Schlüssel-Wert-Paaren dargestellt.
106
107
1
2
public SimpleParameterSet(
java.util.Properties parameters)
Listing 6.9: Konstruktor SimpleParameterSet.java
SimpleQueryMetadata (Class)
QueryMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Sie dient der Repräsentation einer
Datenbank-Abfrage, die beispielsweise benötigt wird, um Trainings- oder Instanzdaten aus einer Datenbank abzufragen. In der prototypischen Implementierung
werden SQL-Statements in Form von java.lang.String-Objekten gespeichert.
Implementierte Interfaces QueryMetadata.java
• java.lang.String queryString: ein String, der die Datenbankabfrage enthält, die ausgeführt werden soll.
1
2
public SimpleQueryMetadata(
java.lang.String queryString)
Listing 6.10: Konstruktor SimpleQueryMetadata.java
SimpleResultDataSet (Class)
ResultDataSet dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces ContentResource.java, ResultDataSet.java
• TimestampMetadata timestamps: Objekt zur Speicherung von
Transaktions- und Gültigkeitszeitstempeln.
• DataSet data: ein abstraktes Datenobjekt zur Repräsentation einer Ergebnisdatenmenge einer Klassifikation.
• ClassifierLocation classifierLocation: die Adresse des
Klassifikators, auf Grundlage dessen die Ergebnisdatenmenge der Klassifikation erzeugt wurde.
• ResultDataSetLocation dataLocation: die Beschreibung des Ortes, an dem die Ergebnisdatenmenge der Klassifikation gespeichert ist.
1
2
3
public SimpleResultDataSet(
TimestampMetadata timestamps,
DataSet data,
107
108
4
5
ClassifierLocation classifierLocation,
ResultDataSetLocation dataLocation)
Listing 6.11: Konstruktor SimpleResultDataSet.java
SimpleResultDataSetLocation (Class)
ResultDataSetLocation dar und dient dem Zwecke der Demonstration der
Funktionsfähigkeit der ReDiCAt-Architektur. Sie beinhaltet die Metadaten zum
Zugriff auf ein Klassifikationsergebnis. Diese bestehen aus dem Namen der Komponente, die die Datenquelle beinhaltet, in der die Klassifikationsergebnisse gespeichert sind, sowie den Benutzernamen und das Passwort zum Zugriff auf diese
Datenquelle.
Implementierte Interfaces ContentResourceLocation.java,
on.java
ResultDataSetLocati-
die Datenquelle beinhaltet, in der die Ergebnisdatenmenge der Klassifikation
gespeichert ist.
• java.lang.String userName: eine String-Repräsentation des Benutzernamens, der benötigt wird, um die Ergebnisdatenmenge der Klassifikation
aus der Datenquelle auszulesen, in der sie gespeichert ist.
• java.lang.String userPasswd: eine String-Repräsentation des
Passwortes, das benötigt wird, um die Ergebnisdatenmenge der Klassifikation aus der Datenquelle auszulesen, in der sie gespeichert ist.
1
2
3
4
public SimpleResultDataSetLocation(
java.lang.String userPasswd)
Listing 6.12: Konstruktor SimpleResultDataSetLocation.java
SimpleSelectedDataSet (Class)
SelectedDataSet dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Sie besteht aus einem prototypischen Datensatz, der eine selektierte Datenmenge repräsentiert, sowie aus den Metadaten
zum Zugriff auf die Datenquelle, aus der die Daten selektiert wurden und einem
TimestampMetadata-Objekt, welches die Zeitstempelung dieses Datensatzes
umsetzt.
Implementierte Interfaces ContentResource.java, SelectedDataSet.java
108
109
die Datenquelle beinhaltet, in der die Ergebnisdatenmenge der Klassifikation
gespeichert ist.
• java.lang.String userName: eine String-Repräsentation des Benutzernamens, der benötigt wird, um die Ergebnisdatenmenge der Klassifikation
aus der Datenquelle auszulesen, in der sie gespeichert ist.
• java.lang.String userPasswd: eine String-Repräsentation des
Passwortes, das benötigt wird, um die Ergebnisdatenmenge der Klassifikation aus der Datenquelle auszulesen, in der sie gespeichert ist.
1
2
3
4
public SimpleSelectedDataSet(
DataSet dataSet,
ContentResourceLocation dataSource,
TimestampMetadata timestamps)
Listing 6.13: Konstruktor SimpleSelectedDataSet.java
SimpleTimestampMetadata (Class)
TimestampMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Es setzt die intervallbasierte Zeitstempelung mit Transaktions- und Gültigkeitszeitstempeln um. Objekte dieser Klasse werden u.a. dazu verwendet, ContentResource-Objekte zu versionieren.
Implementierte Interfaces TimestampMetadata.java
• java.security.Timestamp
anfanges.
tendes.
zeitanfanges.
zeitendes
vtb: der Zeitstempel des Gültigkeitszeitvte: der Zeitstempel des Gültigkeitszeittb: der Zeitstempel des Transaktionstte: der Zeitstempel des Transaktions-
1
2
3
4
5
public SimpleTimestampMetadata(
java.security.Timestamp vtb,
java.security.Timestamp vte,
java.security.Timestamp ttb,
java.security.Timestamp tte)
Listing 6.14: Konstruktor SimpleTimestampMetadata.java
109
110
Die Klassen, die eine prototypische Implementierung der zuvor aufgeführten Interfaces darstellen und zur Umsetzung der ReDiCAt-Architektur zu Demonstrationszwecken implementiert
wurden, sind mit ihren get<Attributname>- und set<Attributname>-Methoden sowie den Assoziationen untereinander und zu den Interfaces, die sie implementieren, in Abbildung 6.2 in Form eines Klassendiagrammes aufgeführt.
110
<<interface>>
SimpleTimestampMetadata
TimestampMetadata
111
Abbildung 6.2.: Klassendiagramm der Interfaces und Klassen zur Abbildung der ADT
<<use>>
getTtb()
getTimestamps()
getTtb()
getTte()
setTimestamps()
getTte()
getVtb()
getVtb()
getVte()
getVte()
SimpleTimestampMetadata()
getUtilisation()
setTtb()
setTtb()
setUtilisation()
setTte()
setTte()
getTaskName()
setVtb()
setVtb()
setTaskName()
setVte()
setVte()
<<use>>
<<interface>>
<<interface>>
ResultDataSet
<<use>>
Classifier
<<interface>>
SelectedDataSet
getData()
getData()
setData()
getLocation()
setDataLocation()
setData()
setLocation()
getLocation()
<<use>>
setData()
setLocation()
<<interface>>
<<interface>>
<<interface>>
QueryMetadata
<<interface>>
MaintenanceTask
<<interface>>
InductionTask
getClassifier()
getClassifierSet()
getClassifierSet()
getControlDBAGK()
getUtilisation()
getUtilisation()
getUtilisation()
setClassifierSet()
setClassifierSet()
setControlDBAGK()
setUtilisation()
setUtilisation()
SimpleClassifier()
setUtilisation()
getTaskName()
getTaskName()
getData()
setClassifier()
setTaskName()
setTaskName()
getDSKAddress()
getDSKAddress()
getDSKAddress()
setDSKAddress()
setDSKAddress()
setDSKAddress()
getQueryString()
getDescription()
setQueryString()
setDescription()
SimpleResultDataSet()
ClassificationTask
DataSet
<<use>>
SimpleResultDataSet
Task
getData()
<<use>>
getDataLocation()
<<interface>>
SimpleSelectedDataSet
SimpleClassifier
SimpleSelectedDataSet()
getData()
getData()
getDataLocation()
getLocation()
SimpleDataSet
getTimestamps()
getTimestamps()
setData()
setData()
SimpleDataSet()
setDataLocation()
setTimestamps()
SimpleQueryMetadata
getLocation()
getTimestamps()
setData()
SimpleQueryMetadata()
getBSKAddress()
getBSKAddresses()
getBSKAddresses()
setLocation()
getDescription()
setLocation()
getQueryString()
setBSKAddress()
setBSKAddresses()
setBSKAddresses()
setTimestamps()
setDescription()
setTimestamps()
setQueryString()
getIVKAddress()
getTaskName()
setIVKAddress()
setTaskName()
<<interface>>
ContentResourceLocation
<<use>>
getDataSourceMD()
setDataSourceMD()
getIVKMetadata()
<<use>>
setIVKMetadata()
<<use>>
<<use>>
ComponentAddress
<<interface>>
ClassifierLocation
<<use>>
getComponentName()
getDataSourceMD()
<<use>>
setComponentName()
getUserName()
SimpleClassificationTask
getDataSourceMD()
getClassifierSet()
getControlDBAGK()
getUtilisation()
getUtilisation()
getUtilisation()
setClassifierSet()
setClassifierSet()
setControlDBAGK()
setUtilisation()
setUtilisation()
setUtilisation()
SimpleMaintenanceTask()
SimpleInductionTask()
SimpleClassificationTask()
getTaskName()
getTaskName()
setClassifier()
setTaskName()
setTaskName()
getTaskName()
SimpleClassifierLocation()
setTaskName()
getDataSourceMD()
getIVKMetadata()
getBSKAddresses()
getUserName()
setIVKMetadata()
setBSKAddresses()
getUserPassword()
getBSKAddress()
getBSKAddresses()
getDSKAddress()
setBSKAddress()
setBSKAddresses()
setDSKAddress()
getDSKAddress()
getDSKAddress()
setDSKAddress()
setDSKAddress()
setDataSourceMD()
setUserName()
setUserName()
setUserPasswd()
setUserPassword()
<<interface>>
ParameterSet
getParameters()
SimpleResultDataSetLocation
SimpleClassifierLocation
<<use>>
SimpleResultDataSetLocation()
<<use>>
getDataSourceMD()
SimpleComponentAddress
getUserPasswd()
SimpleInductionTask
getClassifierSet()
getUserPassword()
setDataSourceMD()
SimpleMaintenanceTask
getClassifier()
<<use>>
getUserName()
getUserPasswd()
getUserName()
<<use>>
<<use>>
<<interface>>
<<interface>>
ResultDataSetLocation
<<interface>>
ContentResource
setUserName()
SimpleComponentAddress()
setDataSourceMD()
setUserPasswd()
getComponentName()
setUserName()
setDataSourceMD()
setComponentName()
setUserPassword()
setParameters()
SimpleParameterSet
SimpleParameterSet()
getParameters()
setParameters()
getIVKAddress()
setIVKAddress()
111
112
6.1.2. Interfaces und prototypische Implementierungen zur
Repräsentation der Kontrollflüsse
In den Analyse-Abläufen, die im Rahmen des ReKlaMe-Projektes durchführbar sind, besteht
an verschiedenen Stellen der Bedarf nach steuernden Metadaten. Damit die Komponenten der
ReDiCAt-Architektur in der Lage sind, die Analyse-Vorgänge durchzuführen, werden spezielle
Metadaten-Formate konzeptioniert. Diese Metadaten-Formate basieren auf den in Abschnitt
6.1.1 entworfenen Interfaces und Klassen und sollen im Folgenden in Abhängigkeit von der
korrespondierenden Komponente dargestellt werden:
Aktualisierungs-Komponente Die Aktualisierungs-Komponente ist mit der Aufgabe betraut, Informationen über durch die Architektur neu erzeugte ContentResourceObjekte wie Klassifikatoren oder Klassifikationsergebnisse in ein globales
Metadaten-Repository einzupflegen. Die Informationen zu solch einem neuen
ContentResource-Objekt umfassen verschiedene Metadaten, die im Folgenden
nacheinander aufgeführt werden.
Zu diesen Metadaten zählt ein String-Objekt, welches den Typ der neu erzeugten Ressource modelliert. Erlaubte Werte sind hier classifier oder
classificationResult.
Weiter wird ein Objekt des Typs ContentResourceLocation benötigt, um die Daten zu beschreiben, die nötig sind, um auf das ContentResource-Objekt zugreifen zu
können. Dazu zählt die Adresse der Komponente, die die Datenquelle beinhaltet, in der
das Objekt gespeichert ist, sowie der Benutzername und das Passwort zum Zugriff auf
die Datenbank.
Zusätzlich wird ein weiteres String-Objekt gespeichert, welches eine Beschreibung
des ContentResource-Objektes beinhaltet. Diese Beschreibung kann einem Benutzer präsentiert werden, damit dieser eine Grundlage zur Einschätzung erhält, ob er die
Ressource sinnvoll für einen potentiellen Analyse-Ablauf verwenden kann.
Schließlich ist noch ein weiteres Objekt vom Typ ContentResourceLocation
in den Metadaten enthalten. Dieses beherbergt die Informationen zum Zugriff
auf die Datenquelle, die die Grundlage der Erzeugung des zu beschreibenden
ContentResource-Objektes darstellte.
Zur Modellierung dieser Metadaten wird ein Interface AKMetadata konzeptioniert,
und in Form der Klasse SimpleAKMetadata wird eine einfache Implementierung
durchgeführt werden. Abbildung 6.3 zeigt das Interface und die implementierende Klasse samt ihrer Abhängigkeiten zu anderen Interfaces und Klassen.
AKMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Kontrolle des Ablaufes der Komponente AK der ReDiCAt-Architektur zur Generierung eines
Metadaten-Eintrages über ein neu erzeugtes ContentResource-Objekt in
ein globales Repository.
Superinterfaces
Subinterfaces
Implementierungen SimpleAKMetadata
• String getContentResourceType(): gibt den Typ der zu
indizierenden Ressource zurück. Dies kann classifier oder
classificationResult sein.
112
113
redicat::metadata::SimpleContentResourceLocation
redicat::metadata::SimpleComponentAddress
SimpleContentResourceLocation()
getDataSourceMD()
getComponentName()
getUserName()
setComponentName()
getUserPasswd()
setDataSourceMD()
setUserName()
<<use>>
setUserPasswd()
<<interface>>
<<interface>>
<<interface>>
redicat::metadata::ContentResourceLocation
AKMetadata
redicat::metadata::ComponentAddress
<<use>>
<<use>>
getContentResourceType()
getDataSourceLocation()
getDataSourceMD()
getComponentName()
setDataSourceMD()
setComponentName()
getDescription()
getLocation()
<<use>>
setContentResourceType()
setDataSourceLocation()
setDescription()
setLocation()
SimpleAKMetadata
SimpleAKMetadata()
<<use>>
<<interface>>
<<interface>>
redicat::metadata::ClassifierLocation
redicat::metadata::ResultDataSetLocation
getDataSourceMD()
getDataSourceMD()
getUserName()
getUserName()
getUserPassword()
getUserPasswd()
setDataSourceMD()
setDataSourceMD()
setUserName()
setUserName()
setUserPassword()
setUserPasswd()
<<use>>
getContentResourceType()
getDataSourceLocation()
getDescription()
getLocation()
redicat::metadata::SimpleClassifierLocation
redicat::metadata::SimpleResultDataSetLocation
setDataSourceLocation()
setDescription()
getDataSourceMD()
getDataSourceMD()
setLocation()
getUserName()
getUserName()
getUserPassword()
getUserPasswd()
setDataSourceMD()
setDataSourceMD()
setUserName()
setUserName()
setUserPassword()
setUserPasswd()
<<use>>
setContentResourceType()
<<use>>
Abbildung 6.3.: Klassendiagramm der Metadaten zur Steuerung der AktualisierungsKomponente AK
• void setContentResourceType(String type): setzt den
Typ der zu indizierenden Ressource auf den Wert des Parameters type.
• ContentResourceLocation getDataSourceLocation: gibt
die Metadaten zurück, die zum Zugriff auf die Datenquelle benötigt werden, deren Daten die Grundlage der Induktion der Ressource darstellen.
Diese Datenquelle kann eine relationale Datenbank sein, aber auch ein
Klassifikator-Repository.
• void setDataSourceLocation(
ContentResourceLocation dataSourceLocation):
setzt die Metadaten, die zum Zugriff auf die Datenquelle benötigt werden,
deren Daten die Grundlage der Induktion der Ressource darstellen, auf
den Parameter dataSourceLocation.
• String getDescription(): gibt eine Beschreibung der zu indizierenden Ressource zurück. Diese Beschreibung kann einem Benutzer in
einem Auswahlprozess präsentiert werden, um ihm eine Grundlage für eine Entscheidung zu bieten, ob dieser die Ressource in einen potentiellen
Analyse-Ablauf mit einbeziehen möchte oder nicht.
• void setDescription(String description): setzt die Beschreibung der zu indizierenden Ressource auf den Wert des Parameters
description.
• ContentResourceLocation getLocation(): gibt die Metadaten zurück, die zum Zugriff auf die zu indizierende Ressource benötigt
werden. Zu diesen Metadaten zählen die Adresse der Komponente, die
die Datenquelle beinhaltet, in der die zu indizierende Ressource gespeichert ist, sowie ein Benutzername und ein Passwort zum Zugriff auf diese
113
114
Datenquelle.
• void setLocation(
ContentResourceLocation location): setzt die
Metadaten, die zum Zugriff auf die zu indizierende Ressource benötigt
werden, auf den Parameter location.
SimpleAKMetadata (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces AKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces AKMetadata.java
• String type: der Typ der zu indizierenden Ressource. Dies kann
classifier oder classificationResult sein.
• ContentResourceLocation dataSourceLocation: die Metadaten, die zum Zugriff auf die Datenquelle benötigt werden, deren Daten
die Basis der Induktion der Ressource darstellen.
• String description: die Beschreibung der zu indizierenden Ressource. Diese Beschreibung kann einem Benutzer in einem Auswahlprozess präsentiert werden, um ihm eine Grundlage für eine Entscheidung zu
bieten, ob dieser die Ressource in einen potentiellen Analyse-Ablauf mit
einbeziehen möchte oder nicht.
• ContentResourceLocation location: die Metadaten, die zum
Zugriff auf die zu indizierende Ressource benötigt werden. Zu diesen Metadaten zählen die Adresse der Komponente, die die Datenquelle beinhaltet, in der die zu indizierende Ressource gespeichert ist, sowie ein Benutzername und ein Passwort zum Zugriff auf diese Datenquelle.
1
2
3
4
5
public SimpleAKMetadata(
java.lang.String contentResourceType,
ContentResourceLocation location,
java.lang.String description,
ContentResourceLocation dataSourceLocation)
Listing 6.15: Konstruktor SimpleAKMetadata.java
Methoden Es werden get<Attribut>() und set<Attribut>()Methoden für jedes vorhandene Attribut implementiert.
Basisklassifikator-Selektion Die zur Selektion eines Basisklassifikators benötigten Informationen umfassen zunächst Informationen über die Komponente, die den Basisklassifikator beherbergt. Dies kann ein Klassifikator-Repository sein, welches sich lokal vorfindet, es kann jedoch in einem verteilten Szenario auch an einem entfernten Ort vorliegen.
Zusätzlich zu den Informationen zur Lokalisierung des Basisklassifikators sind Metadaten zu übergeben, die für den Zugang zu den zu selektierenden Daten benötigt werden.
Dies kann beispielsweise ein Wertepaar aus Benutzername und Passwort für eine Datenquelle sein.
Weiterhin ist es erforderlich, der Selektions-Komponente mitzuteilen, an welche Komponente sie den selektierten Basisklassifikator übergeben soll. Dazu müssen ebenfalls
Informationen über den Ort, an dem sich die Ziel-Komponente befindet, in den Metadaten enthalten sein.
114
115
Schließlich muss der Komponente noch mitgeteilt werden, an welche Instanz sie eine quittierende Nachricht senden soll, die indiziert, dass der Klassifikator erfolgreich
ausgeliefert wurde. Da die Analysen sowohl zentral als auch lokal initiiert werden
können, kommen für den Empfang einer solchen Bestätigung verschiedene MetadatenVerwaltungs-Komponenten in Frage.
Somit wird ein Interface BSKMetadata konzeptioniert, über das sich die
Basisklassifikator-Selektions-Komponente steuern lässt. Es beinhaltet die abstrakten
Datentypen ComponentAddress zur Abbildung der Adresse einer Komponente und
ClassifierLocation zur Durchführung einer Klassifikator-Selektion. Eine einfache Implementierung des Interfaces wird durch die Klasse SimpleBSKMetadata
gegeben. Die Klassen und Interfaces, die das Metadatenpaket zur Steuerung der
Basisklassifikator-Selektions-Komponente umsetzen, sind in Abbildung 6.4 dargestellt.
<<use>>
<<interface>>
BSKMetadata
<<interface>>
getClassifierMD()
getComponentMD()
getDataSourceMD()
getReceiptMD()
setDataSourceMD()
setClassifierMD()
setComponentMD()
setReceiptMD()
<<use>>
<<use>>
<<interface>>
getComponentName()
SimpleBSKMetadata
<<interface>>
setComponentName()
SimpleBSKMetadata()
getClassifierMD()
getComponentMD()
<<use>>
<<use>>
getUserName()
getReceiptMD()
setClassifierMD()
getDataSourceMD()
getUserPassword()
setDataSourceMD()
<<use>>
setComponentMD()
setUserName()
setReceiptMD()
setUserPassword()
Abbildung 6.4.: Klassendiagramm der Metadaten zur Basisklassifikator-Selektion
BSKMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Kontrolle des Ablaufes
der Komponente BSK der ReDiCAt-Architektur zur Selektion eines Klassifikators.
Superinterfaces
Subinterfaces
Implementierungen SimpleBSKMetadata
• ClassifierLocation getClassifierMD(): gibt die Beschreibung des Ortes zurück, an dem der Klassifikator liegt, der selektiert werden soll.
• void setClassifierMD(
ClassifierLocation classifierMD): setzt den Ort,
an dem ein Klassifikator liegt, auf den Wert classifierMD.
• ComponentAddress getComponentMD(): gibt die Adresse der
Komponente zurück, an die der zu selektierende Klassifikator gesendet
werden soll.
• void setComponentMD(ComponentAddress componentMD):
setzt die Adresse der Komponente, an die der zu selektierende Klassifikator gesendet werden soll, auf den Parameter componentMD.
115
116
• ComponentAddress getReceiptMD(): gibt die Adresse der
Komponente zurück, an die die Bestätigungsnachricht der erfolgreichen
Auslieferung des selektierten Klassifikators zu senden ist.
• void setReceiptMD(ComponentAddress receiptMD):
setzt die Adresse der Komponente, an die die Bestätigungsnachricht
der erfolgreichen Auslieferung des selektierten Klassifikators zu senden
ist, auf den Parameter receiptMD.
SimpleBSKMetadata (Class)
BSKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces BSKMetadata.java
• ComponentAddress componentMD: die Adresse der Komponente,
an die der zu selektierende Klassifikator gesendet werden soll.
• ComponentAddress receiptMD: die Adresse der Komponente, an
die die Bestätigungsnachricht der erfolgreichen Auslieferung des selektierten Klassifikators zu senden ist.
• ClassifierLocation classifierMD: die Adresse des Klassifikators, der selektiert werden soll.
1
2
3
4
public SimpleBSKMetadata(
ComponentAddress componentMD,
ComponentAddress receiptMD,
ClassifierLocation classifierMD)
Listing 6.16: Konstruktor SimpleBSKMetadata.java
{Trainings-, Instanz-}Daten-Selektion Um eine Datenmenge zu selektieren, bedarf es
mehrerer Informationen. So muss der Name der Komponente, die die Datenquelle beinhaltet, aus der die Daten selektiert werden sollen, bekannt sein. Auch die Zugangsdaten
zum Zugriff auf die Datenquelle, wie z.B. der Benutzername oder das Passwort, müssen
vorhanden sein.
Weiter werden Informationen über die zu selektierenden Daten benötigt, beispielsweise
die Namen der zu selektierenden Attribute oder ein fertiges SQL-Statement zur Selektion
der Daten. Da die Implementierung prototypisch erfolgt, findet hier eine Einschränkung
auf die Übergabe der String-Repräsentation eines SQL-Statements statt.
Zusätzlich muss der Selektions-Komponente noch die Adresse der Komponente mitgeteilt werden, an die die selektierten Daten übergeben werden sollen.
Schließlich ist die Adresse der Komponente anzugeben, an die im Falle der erfolgreichen
Auslieferung des zu selektierenden Datensatzes eine quittierende Nachricht zu senden
ist.
Das Interface DSKMetadata, welches die zur Datenselektion benötigten Metadaten modelliert, ist zusammen mit den von ihr genutzten ADT-Klassen
ContentResourceLocation zur Beschreibung, Lokalisierung und Durchführung
des Zugriffes einer Datenquelle, ComponentAddress zur Abbildung der Adresse einer Komponente und QueryMetadata zur Repräsentation einer Datenbank-Abfrage
116
117
sowie der Klasse SimpleDSKMetadata, die eine einfache Implementierung des
Interfaces DSKMetadata darstellt, in Abbildung 6.5 aufgeführt.
<<interface>>
DSKMetadata
<<use>>
getComponentMD()
<<use>>
setComponentMD()
getDataSourceMD()
setDataSourceMD()
getQueryMD()
<<interface>>
setQueryMD()
getReceiptMD()
getDataSourceMD()
setReceiptMD()
setDataSourceMD()
<<use>>
<<use>>
<<interface>>
redicat::metadata::QueryMetadata
SimpleDSKMetadata
getQueryString()
SimpleDSKMetadata()
setQueryString()
getComponentMD()
<<use>>
setComponentMD()
getDataSourceMD()
setDataSourceMD()
<<interface>>
getQueryMD()
<<use>>
setQueryMD()
<<use>>
getReceiptMD()
getComponentName()
setReceiptMD()
setComponentName()
Abbildung 6.5.: Klassendiagramm der Metadaten zur Daten-Selektion
DSKMetadata (Interface)
Beschreibung Modelliert einen ADT zur Kontrolle des Ablaufes der Komponente DSK der ReDiCAt-Architektur zur Selektion eines Datensatzes aus einer Datenquelle.
Superinterfaces Subinterfaces Implementierungen SimpleDSKMetadata.java
• ComponentAddress getComponentMD(): gibt die Adresse der
Komponente zurück, an die die zu selektierende Datenmenge übergeben
werden soll.
• void setComponentMD(
ComponentAddress componentMD): setzt die Adresse
der Komponente, an die die zu selektierende Datenmenge übergeben werden soll, auf den Parameter componentMD.
• ContentResourceLocation getDataSourceMD(): gibt die
Metadaten zum Zugriff auf die Datenquelle zurück, in der sich die zu
selektierenden Daten befinden.
• void setDataSourceMD(
ContentResourceLocation dataSourceMD): setzt
die Metadaten zum Zugriff auf die Datenquelle, in der sich die zu selektierenden Daten befinden, auf den Parameter dataSourceMD.
• QueryMetadata getQueryMD(): gibt den ADT zur Beschreibung
der Datenbankabfrage zurück, auf Basis derer die Selektion durchgeführt
werden soll.
117
118
• void setQueryMD(QueryMetadata queryMD): setzt den ADT
zur Beschreibung der Datenbankabfrage, auf Basis derer die Selektion
durchgeführt werden soll, auf den Parameter queryMD.
Auslieferung der selektierten Datenmenge zu senden ist.
setzt die Adresse der Komponente, an die die Bestätigungsnachricht
der erfolgreichen Auslieferung der selektierten Datenmenge zu senden
ist, auf den Parameter receiptMD.
SimpleDSKMetadata (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces DSKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. Anhand der Objekte dieser Klasse
werden in der prototypischen Implementierung der Architektur die Instanzund Trainingsdatensätze durch die Komponente DSK selektiert werden.
Implementierte Interfaces DSKMetadata.java
• ComponentAddress componentMD: die Adresse der Komponente,
an die die zu selektierende Datenmenge gesendet werden soll.
• ComponentAddress receiptMD: die Adresse der Komponente, an
die die Bestätigungsnachricht der erfolgreichen Auslieferung der zu selektierenden Daten gesendet werden soll.
• ContentResourceLocation dataSourceMD: die Metadaten
zum Zugriff auf die Datenquelle, aus der die Datenmenge selektiert
werden soll.
• QueryMetadata queryMD: der ADT zur Beschreibung der Datenbankabfrage, auf Basis derer die Selektion der Datenmenge durchgeführt
werden soll.
1
2
3
4
5
public SimpleDSKMetadata(
ComponentAddress componentMD,
ContentResourceLocation dataSourceMD,
QueryMetadata queryMD)
Listing 6.17: Konstruktor SimpleDSKMetadata.java
DB-Abfrage-Generierungs-Komponente Die DB-Abfrage-Generierungs-Komponente
benötigt zur Generierung von Datenbank-Abfragen aus einer Menge von Selection Graphs Informationen über die Datenquelle, der sie die Abfragen stellen soll. Zu diesem
Zweck werden ihr Metadaten zum Zugriff auf die Datenquelle übergeben.
Zusätzlich wird ein ADT benötigt, der die Selection Graph-Menge modelliert, auf Basis
derer die Datenbank-Abfragen generiert werden sollen
Weiterhin ist die Adresse der Komponente vonnöten, an die eine Bestätigung der erfolgreichen Auslieferung der generierten Datenbank-Abfragen an eine weiterverarbeitende
Komponente gemeldet werden soll.
118
119
Das Interface DBAGKMetadata, das den Metadatensatz zur Steuerung der DBAGKKomponente der ReDiCAt-Architektur umsetzt, ist in Abbildung 6.6 zusammen mit den
assoziierten Interfaces und der Klasse SimpleDBAGKMetadata, die eine einfache
Implementierung des Interfaces darstellt, abgebildet. Das Interface beinhaltet die Metadaten zum Zugriff auf die Datenquelle in Form eines ContentResourceLocationObjektes sowie ein DataSet-Objekt, welches den ADT zur Modellierung der Selection
Graphs darstellt, und ein ComponentAddress-Objekt, welches die Adresse der die
Quittung empfangenden Komponente beinhaltet.
<<interface>>
<<interface>>
DBAGKMetadata
<<use>>
getDataSourceMD()
getDataSourceMD()
setDataSourceMD()
setDataSourceMD()
getReceiptMD()
setReceiptMD()
<<use>>
getSelectionGraphSet()
setSelectionGraphSet()
<<use>>
<<interface>>
getComponentName()
setComponentName()
SimpleDBAGKMetadata
<<use>>
getDataSourceMD()
setDataSourceMD()
getReceiptMD()
setReceiptMD()
<<use>>
SimpleDBAGKMetadata()
getSelectionGraphSet()
setSelectionGraphSet()
Abbildung 6.6.: Klassendiagramm der Metadaten zur Steuerung der Datenbank-AbfrageGenerierungs-Komponente
DBAGKMetadata (Interface)
der Komponente DBAGK der ReDiCAt-Architektur zur Generierung von Datenbankabfragen aus Selection Graphs zur Klassifikation der Elemente einer
Datenmenge.
Superinterfaces Subinterfaces Implementierungen SimpleDBAGKMetadata.java
• ContentResourceLocation getDataSourceMD(): gibt die
Metadaten zum Zugriff auf die Datenbank zurück, auf deren Daten die
generierten Datenbankabfragen angewendet werden sollen.
• void setDataSourceMD(
ContentResourceLocation dataSourceMD): setzt
die Metadaten zum Zugriff auf die Datenbank, auf deren Daten die generierten Datenbankabfragen angewendet werden sollen, auf den Parameter
dataSourceMD.
Durchführung der Abfrage-Generierung und -anwendung zu senden ist.
119
120
setzt die Adresse der Komponente, an die die Bestätigungsnachricht der
erfolgreichen Durchführung der Abfrage-Generierung und -anwendung
zu senden ist, auf den Parameter receiptMD.
• DataSet getSelectionGraphSet(): gibt den ADT zurück, der
die Menge der Selection Graphs modelliert, aus denen DatenbankAbfragen abgeleitet werden sollen.
• void setSelectionGraphSet(
DataSet selectionGraphSet): setzt den ADT,
der die Menge der Selection Graphs modelliert, aus denen die
Datenbank-Abfragen abgeleitet werden sollen, auf den Parameter
selectionGraphSet.
SimpleDBAGKMetadata (Class)
DBAGKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur. In der prototypischen Implementierung wird das DataSet-Objekt, welches die Selection Graphs modellieren
soll, nicht mit Semantik versehen werden. Vielmehr wird lediglich ein syntaktischer Nutzen für die Komponenten DBAGK und SGAK gegeben sein.
Implementierte Interfaces DBAGKMetadata.java
• ContentResourceLocation dataSourceMD: die Adresse der
Komponente, die die Datenbank beinhaltet.
• ComponentAddress receiptMD: die Adresse der Komponente,
an die die Bestätigungsnachricht der erfolgreichen Durchführung der
Abfrage-Generierung und -anwendung zu senden ist.
• DataSet selectionGraphSet: der ADT, der die Menge der Selection Graphs modelliert, aus denen die Datenbank-Abfragen abgeleitet
werden sollen. Die Implementierung wird keine semantische Umsetzung
einer Menge von Selection Graphs darstellen, sondern dient lediglich der
prototypischen Umsetzung einer Selection Graph-Menge.
1
2
3
4
public SimpleDBAGKMetadata(
ContentResourceLocation dataSourceMD,
DataSet selectionGraphSet)
Listing 6.18: Konstruktor SimpleDBAGKMetadata.java
Invalidierungs-Komponente Die Invalidierungs-Komponente erfordert verschiedene Metadaten zur Steuerung ihres Ablaufes. So ist zunächst die Adresse der globalen Uhr
vonnöten, um einen Zeitstempel erzeugen zu können.
Der zeitgestempelte Klassifikator soll anschließend in einer Datensenke gespeichert werden. Dazu sind die Metadaten zum Zugriff auf die Datensenke vonnöten.
Schließlich bedarf es der Adresse der Komponente, an die die Bestätigung der erfolgreichen Auslieferung des invalidierten Klassifikators an die vorgesehene Datensenke gesendet werden soll.
120
121
Abbildung 6.7 stellt das Interface IVKMetadata dar, das einen Metadatensatz repräsentiert, der diese Informationen beinhaltet. Sie beinhaltet ein Objekt vom Typ
ContentResourceLocation zur Repräsentation der Datensenke sowie zwei Objekte vom Typ ComponentAddress, die die Adresse der globalen Uhr sowie die
Adresse der Komponente, die die Quittung der erfolgreichen Auslieferung des invalidierten Klassifikators empfangen soll, beinhalten. Ebenfalls dargestellt wird die Klasse SimpleIVKMetadata, die eine prototypische Implementierung des Interfaces
IVKMetadata ist.
<<interface>>
IVKMetadata
<<interface>>
<<use>>
getDataSinkMD()
getDataSourceMD()
setDataSinkMD()
setDataSourceMD()
getGlobalClockMD()
setGlobalClockMD()
getReceiptMD()
setReceiptMD()
<<use>>
<<use>>
SimpleIVKMetadata
<<interface>>
SimpleIVKMetadata()
getDataSinkMD()
getComponentName()
setDataSinkMD()
setComponentName()
<<use>>
getGlobalClockMD()
setGlobalClockMD()
getReceiptMD()
<<use>>
setReceiptMD()
Abbildung 6.7.: Klassendiagramm
Komponente
der Metadaten zur Steuerung der Invalidierungs-
IVKMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Kontrolle des Ablaufes der
Komponente IVK zur Invalidierung von Klassifikatoren.
Superinterfaces Subinterfaces Implementierungen SimpleIVKMetadata.java
• ContentResourceLocation getDataSinkMD(): gibt die Metadaten zum Zugriff auf die Datensenke zurück, in der der zu invalidierende Klassifikator gespeichert werden soll.
• void setDataSinkMD(
ContentResourceLocation dataSinkMD): setzt die Metadaten zum Zugriff auf die Datensenke, in der der zu invalidierende Klassifikator gespeichert werden soll, auf den Parameter dataSinkMD.
• ComponentAddress getGlobalClockMD(): gibt die Adresse der
Komponente zurück, von der die globale Uhrzeit der ReDiCAt-Architektur
erfragt werden kann.
• void setGlobalClockMD(
ComponentAddress globalClockMD): setzt die Adresse
der Komponente, von der die globale Uhrzeit der ReDiCAt-Architektur erfragt
werden kann, auf den Parameter globalClockMD.
121
122
• ComponentAddress getReceiptMD(): gibt die Adresse der Komponente zurück, an die die Bestätigungsnachricht der erfolgreichen Auslieferung
des invalidierten Klassifikators zu senden ist.
• void setReceiptMD(ComponentAddress receiptMD): setzt die
Adresse der Komponente, an die die Bestätigungsnachricht der erfolgreichen
Auslieferung des invalidierten Klassifikators zu senden ist, auf den Parameter
receiptMD.
SimpleIVKMetadata (Class)
IVKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces IVKMetadata.java
• ComponentAddress globalClockMD: die Adresse der Komponente,
von der die globale Zeit der ReDiCAt-Architektur erfragt werden kann.
• ContentResourceLocation dataSinkMD: die Metadaten zum Zugriff auf die Datensenke, in der der zu invalidierende Klassifikator gespeichert
werden soll.
• ComponentAddress receiptMD: die Adresse der Komponente, an die
die Bestätigungsnachricht der erfolgreichen Auslieferung des invalidierten
Klassifikators zu senden ist.
1
2
3
4
public SimpleIVKMetadata(
ComponentAddress globalClockMD,
ContentResourceLocation dataSinkMD,
ComponentAddress receiptMD)
Listing 6.19: Konstruktor SimpleIVKMetadata.java
Benutzungsschnittstelle Die Benutzungsschnittstelle nimmt in zwei verschiedenen Phasen der Analyse an deren Ablauf teil: einmal initial, einmal anschließend an die Recherche nach bereits vorhandenen Klassifikatoren oder Klassifikationsergebnissen.
Im initialen Durchlauf bekommt sie die notwendigen Informationen durch den Benutzer über die Benutzungsoberfläche mitgeteilt. Aus diesen Informationen kann sie
dann ein Metadaten-Objekt TAMetadata generieren, welches später genau beschrieben wird. Auf Basis dieses ersten generierten Metadaten-Objektes, welches der TaskAnalyse-Komponente übergeben wird, werden im Anschluss bereits im System vorhandene Klassifikatoren oder Klassifikationsergebnisse gesucht. Dieser Metadatensatz
muss Informationen über den durchzuführenden Ablauf beinhalten, also beschreiben, ob
eine Klassifikator-Induktion, eine Anwendung oder eine Wartung eines Klassifikators
durchgeführt werden soll. Weiter sind Informationen über die der potentiellen Analyse
zu Grunde liegenden Daten vonnöten. So kann ein entsprechender Klassifikator oder ein
bereits vorhandenes Klassifikationsergebnis nur anhand einer Beschreibung aufgefunden
werden. Ergebnisse einer Klassifikator-Anwendung müssen zudem auf den verwendeten
Klassifikator und auf die Datenquelle verweisen, aus der die Instanzdaten stammen.
122
123
Im zweiten Durchlauf wird ein Metadatenpaket von der Task-Analyse-Komponente
empfangen. Dieses beinhaltet potentiell gefundene, im System vorhandene Klassifikatoren oder Klassifikationsergebnisse, die dem Benutzer anschließend zur Auswahl für weitere Analyseschritte präsentiert werden. Durch die Eingaben des Benutzers kann dann ein
weiteres Metadaten-Objekt generiert werden, welches den weiteren Verlauf der Analyse bestimmt. Dieses muss die Information über die Art des Analyse-Ablaufes beinhalten, sowie alle Adressen von zu verwendenden Klassifikatoren und Datenmengen. Insgesamt müssen in diesem Metadaten-Objekt alle Informationen für alle nachfolgend an der
Analyse beteiligten Komponenten enthalten sein, da dieses die Steuerung des AnalyseAblaufes festlegt und vorgibt. Dementsprechend wird es für jeden Analyse-Ablauf ein
eigenes Metadaten-Objekt geben.
Die in Abbildung 6.8 abgebildete Klasse SimpleBSMetadata ist vom Interface
BSMetadata abgeleitet und repräsentiert die Metadatenmenge zur Steuerung der
Benutzungsschnittstellen-Komponente. Sie beinhaltet ein Vector-Objekt, in dem
ContentResource-Objekte enthalten sind, die durch die von der Komponente TA
initiierte Suche gefunden wurden. Diese Objekte können Klassifikatoren oder Klassifikationsergebnisse beinhalten. Die Klasse beinhaltet zudem ein Task-Objekt, welches
den durchzuführenden Analyse-Ablauf repräsentiert, und ein TAMetadata-Objekt zur
Übergabe der für die Suche nach ContentResource-Objekten notwendigen Metadaten an die Komponente TA.
<<interface>>
<<interface>>
BSMetadata
TAMetadata
getResultContentResources()
getAttributes()
<<use>>
getTask()
getContentResourcesFound()
setResultContentResources()
getDataSources()
setTask()
getSearchMD()
setAttributes()
<<use>>
<<interface>>
setContentResourcesFound()
redicat::metadata::Task
setSearchMD()
<<use>>
setDataSources()
getTask()
getUtilisation()
setTask()
setUtilisation()
SimpleBSMetadata
<<use>>
getTaskName()
setTaskName()
resultContentResources: Vector
searchMD: TAMetadata
task: Task
<<use>>
<<interface>>
SimpleBSMetadata()
VKMetadata
getResultContentResources()
getUtilisation()
getTask()
setResultContentResources()
setUtilisation()
getSinkLocation()
setTask()
getSearchMD()
setSearchMD()
setSinkLocation()
<<use>>
Abbildung 6.8.: Klassendiagramm der Metadaten zur Steuerung der BenutzungsschnittstellenKomponente
BSMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Kontrolle des Ablaufes der Komponente BS der ReDiCAt-Architektur zur Schaffung einer Benutzungsschnittstelle für die ReDiCAt-Architektur.
Superinterfaces Subinterfaces Implementierungen SimpleBSMetadata.java
123
124
• java.util.Vector getResultContentResources(): gibt
die gefundenen ContentResource-Objekte zurück, die von der Komponente TA auf Basis der in TAMetadata spezifizierten Eigenschaften
gefunden wurden.
• void setResultContentResources(
java.util.Vector resultContentResources):
setzt die gefundenen ContentResource-Objekte, die von der Komponente TA auf Basis der in TAMetadata spezifizierten Eigenschaften
gefunden wurden, auf den Parameter resultContentResources.
• TAMetadata getSearchMD(): gibt das Objekt zurück, das die Metadatenmenge repräsentiert, auf Basis derer nach bereits vorhandenen
ContentResource-Objekten wie Klassifikatoren oder Klassifikationsergebnissen gesucht werden soll.
• void setSearchMD(TAMetadata searchMD): setzt das Objekt, das die Metadatenmenge repräsentiert, auf Basis derer nach bereits vorhandenen ContentResource-Objekten wie Klassifikatoren
oder Klassifikationsergebnissen gesucht werden soll, auf den Parameter
searchMD.
• Task getTask(): gibt das Objekt zurück, das die Metadatenmenge zur Beschreibung eines Analyse-Ablaufes repräsentiert, der von der
ReDiCAt-Architektur durchgeführt werden kann.
• void setTask(Task task): setzt das Objekt, das die Metadatenmenge zur Beschreibung eines Analyse-Ablaufes repräsentiert, der von
der ReDiCAt-Architektur durchgeführt werden kann, auf den Parameter
task.
SimpleBSMetadata (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces BSMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces BSMetadata.java
• Task task: das Objekt zur Repräsentation einer Metadatenmenge, die
den Analyse-Ablauf beschreibt, der von der ReDiCAt-Architektur durchgeführt werden soll. Möglich sind hier:
– Induktion eines Klassifikators
– Anwendung eines Klassifikators
– Wartung eines Klassifikators
• TAMetadata searchMD: das Objekt zur Repräsentation einer Metadatenmenge, die die Task-Analyse steuert und die Kriterien für die Suche
nach bereits vorhandenen ContentResource-Objekten beinhaltet.
• java.util.Vector resultContentResources: ein Vector zur
Speicherung der gefundenen ContentResource-Objekte, die von der
Komponente TA zurückgegeben wurden.
1
2
3
public SimpleBSMetadata(
Task task,
TAMetadata searchMD)
Listing 6.20: Konstruktor SimpleBSMetadata.java
124
125
Nach Maßgabe des Betreuers dieser Arbeit wird auf die Implementierung dieser Komponente und der ADT, die diese Komponente steuern, verzichtet.
Task-Analyse Die Aufgabe der Task-Analyse-Komponente besteht darin, die für
einen Analyse-Vorgang potentiell interessanten, bereits im System vorhandenen
ContentResource-Objekte aufzufinden und an die Benutzungsschnittstelle zu übergeben. Dazu erhält sie von der Benutzungsschnittstelle eine Menge von Metadaten,
welche Informationen über den durchzuführenden Analyseschritt und die zur Analyse
zu verwendenden Datenmengen und -quellen beinhaltet. Sie stellt eine Suchanfrage
an die Metadaten-Verwaltungs-Komponente, die gefundene Ergebnisse in Form eines
Vector-Objektes zurück gibt. Dieses wird anschließend an die Benutzungsschnittstelle
weitergegeben.
Die Klasse SimpleTAMetadata implementiert das Interface TAMetadata und
beinhaltet einen Vector zur Speicherung von Attributnamen und einen Vector
zur Speicherung von Datenquellen-Adressen, nach denen in den Beschreibungen der
ContentResources gesucht werden soll. Weiter beinhaltet sie einen Vector zur
Speicherung der gefundenen ContentResource-Objekte sowie ein Task-Objekt zur
Repräsentation des aktuell durchzuführenden Analyse-Ablaufes. Alle beteiligten Klassen sind in Abbildung 6.9 dargestellt.
<<interface>>
<<interface>>
TAMetadata
<<use>>
getAttributes()
getTaskName()
setTaskName()
getDataSources()
getUtilisation()
getTask()
setUtilisation()
setAttributes()
setDataSources()
setTask()
SimpleTAMetadata
<<use>>
attributes: Vector
contentResourcesFound: Vector
dataSources: Vector
task: Task
SimpleTAMetadata()
getAttributes()
getDataSources()
getTask()
setAttributes()
setDataSources()
setTask()
Komponente
der
Metadaten
zur
Steuerung
der
Task-Analyse-
TAMetadata (Interface)
der Komponente TA zur Suche nach bereits im System vorhandenen, für einen
Analyse-Ablauf potentiell interessanten ContentResource-Objekten wie
Klassifikatoren oder Klassifikationsergebnissen.
125
126
Superinterfaces Subinterfaces Implementierungen SimpleTAMetadata.java
• Task getTask(): gibt das Objekt zurück, das die Metadatenmenge zur Beschreibung eines Analyse-Ablaufes repräsentiert, der von der
task.
• java.util.Vector getAttributes(): gibt den Vector
zurück, der die Attributnamen beinhaltet, nach denen in den Beschreibungen der ContentResource-Objekte gesucht werden soll.
• void setAttributes(java.util.Vector attributes):
setzt den Vector, der die Attributnamen beinhaltet, nach denen in den
Beschreibungen der ContentResource-Objekte gesucht werden soll,
auf den Parameter attributes.
• java.util.Vector getContentResourcesFound(): gibt
den Vector zurück, der die gefundenen ContentResource-Objekte
beinhaltet, die den Suchkriterien entsprechen.
• void setContentResourcesFound(
java.util.Vector contentResourcesFound):
setzt den Vector, der die gefundenen ContentResource-Objekte
beinhaltet, die den Suchkriterien entsprechen, auf den Parameter
contentResourcesFound.
• java.util.Vector getDataSources(): gibt den Vector
zurück, der die Objekte zur Beschreibung des Zugriffes auf Datenquellen beinhaltet, nach denen die ContentResource-Objekte durchsucht
werden sollen.
• void setDataSources(java.util.Vector dataSources):
setzt den Vector, der die Objekte zur Beschreibung des Zugriffes auf
Datenquellen beinhaltet, nach denen die ContentResource-Objekte
durchsucht werden sollen, auf den Parameter dataSources.
SimpleTAMetadata (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces TAMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces TAMetadata.java
– Induktion eines Klassifikators
– Anwendung eines Klassifikators
– Wartung eines Klassifikators
• java.util.Vector attributes: ein Vector zur Speicherung der Attributnamen, nach denen in den Beschreibungen der
ContentResource-Objekte gesucht werden soll.
126
127
• java.util.Vector dataSources: ein Vector zur Speicherung
der Objekte zur Beschreibung der Adresse der Datenquellen, nach denen
in den Beschreibungen der ContentResource-Objekte gesucht werden soll.
• java.util.Vector contentResourcesFound: ein Vector zur
Speicherung der gefundenen ContentResource-Objekte, die den
Suchkriterien entsprechen.
1
2
3
4
5
public SimpleTAMetadata(
Task task,
java.util.Vector attributes,
java.util.Vector dataSources,
java.util.Vector contentResourcesFound)
Listing 6.21: Konstruktor SimpleTAMetadata.java
Nach Maßgabe des Betreuers dieser Arbeit wird auf die Implementierung dieser Komponente und der ADT, die diese Komponente steuern, verzichtet. Anstelle der Komponenten BS und TA wird eine Java-Client-Applikation implementiert, die eine direkte Ansteuerung der Komponente zur Verwaltung der Metadaten und Steuerung des AnalyseAblaufes erlaubt.
Metadaten-Verwaltungs-/Steuerungs-Komponente Die Aufgabe der MetadatenVerwaltungs-/Steuerungs-Komponente besteht in der Verwaltung der Metadaten zur
Durchführung des Analyse-Ablaufes und der Steuerung der Komponenten, die an den
verschiedenen Analyse-Abläufen beteiligt sind. Dazu bedarf es mehrerer Informationen.
Zur Durchführung des ersten Prozesses eines Analyse-Ablaufes, an dem diese Komponente partizipiert, einer Suche nach bereits im System vorhandenen Objekten des
Typs ContentResource, bedarf es je einem Vector-Objekt zur Speicherung der
Attribute, nach denen gesucht werden soll, und einem zur Speicherung der Beschreibungen der Datenquellen, deren Inhalte durchsucht werden sollen. Die gefundenen
ContentResource-Objekte werden in einem weiteren Vector-Objekt gespeichert.
Für den zweiten Prozess des Ablaufes bedarf es des Vorhandenseins eines TaskObjektes, das alle notwendigen Informationen zur Durchführung eines AnalyseAblaufes beinhaltet.
Die Klasse SimpleMVSKMetadata, die das Interface MVSKMetadata implementiert, beinhaltet diese Vector-Objekte sowie ein Task-Objekt zur Speicherung der Informationen zum durchzuführenden Analyse-Ablauf. Die zur Steuerung der Komponente MVSK benötigten Klassen und Interfaces sind in Abbildung 6.10 dargestellt.
MVSKMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Kontrolle des Ablaufes der Komponente MVSK zur Metadaten-Verwaltung und Steuerung der
Abläufe der ReDiCAt-Architektur.
Superinterfaces Subinterfaces Implementierungen SimpleMVSKMetadata.java
127
128
<<interface>>
<<interface>>
MVSKMetadata
<<use>>
getAttributesToSearch()
getUtilisation()
setUtilisation()
getDataSourcesToSearch()
getTaskName()
getTask()
setTaskName()
setAttributesToSearch()
setDataSourcesToSearch()
setTask()
SimpleMVSKMetadata
attributesToSearch: Vector
contentResourcesFound: Vector
dataSourcesToSearch: Vector
task: Task
SimpleMVSKMetadata()
getAttributesToSearch()
<<use>>
getDataSourcesToSearch()
getTask()
setAttributesToSearch()
setDataSourcesToSearch()
setTask()
Abbildung 6.10.: Klassendiagramm der Metadaten zur Steuerung der Metadaten-Verwaltungs/Steuerungs-Komponente
• java.util.Vector getAttributesToSearch(): gibt den
Vector zurück, der die Attributnamen beinhaltet, nach denen in den
Beschreibungen der ContentResource-Objekte gesucht werden soll.
• void setAttributesToSearch(
java.util.Vector attributesToSearch): setzt
den Vector, der die Attributnamen beinhaltet, nach denen in den Beschreibungen der ContentResource-Objekte gesucht werden soll, auf
den Parameter attributesToSearch.
• java.util.Vector getContentResourcesFound(): gibt
den Vector zurück, der die gefundenen ContentResource-Objekte
beinhaltet, die den Suchkriterien entsprechen.
• void setContentResourcesFound(
java.util.Vector contentResourcesFound):
setzt den Vector, der die gefundenen ContentResource-Objekte
beinhaltet, die den Suchkriterien entsprechen, auf den Parameter
contentResourcesFound.
• java.util.Vector getDataSourcesToSearch(): gibt den
Vector zurück, der die Objekte zur Beschreibung des Zugriffes auf
Datenquellen beinhaltet, nach denen die ContentResource-Objekte
durchsucht werden sollen.
• void setDataSources(
java.util.Vector dataSourcesToSearch): setzt
den Vector, der die Objekte zur Beschreibung des Zugriffes auf Datenquellen beinhaltet, nach denen die ContentResource-Objekte
durchsucht werden sollen, auf den Parameter dataSources.
• Task getTask(): gibt das Objekt zurück, das die Metadatenmen-
128
129
ge zur Beschreibung eines Analyse-Ablaufes repräsentiert, der von der
task.
SimpleMVSKMetadata (Class)
MVSKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces MVSKMetadata.java
– naive zur naiven Anwendung eines Klassifikators
– sg zur Klassifikation über Selection Graphs
– ci zur einfachen Induktion eines Klassifikators
– ici zur inkrementellen Induktion eines Klassifikators
– ml für einen Meta-Lern-Vorgang maintenance zur Wartung eines Klassifikators
• java.util.Vector attributesToSearch: ein Vector zur Speicherung der Attributnamen, nach denen in den Beschreibungen der
ContentResource-Objekte gesucht werden soll.
• java.util.Vector dataSourcesToSearch: ein Vector zur
Speicherung der Objekte zur Beschreibung der Adresse der Datenquellen,
nach denen in den Beschreibungen der ContentResource-Objekte
gesucht werden soll.
• java.util.Vector contentResourcesFound: ein Vector zur
Speicherung der gefundenen ContentResource-Objekte, die den
Suchkriterien entsprechen.
1
2
3
4
5
public SimpleMVSKMetadata(
Task task,
java.util.Vector attributesToSearch,
java.util.Vector dataSourcesToSearch,
java.util.Vector contentResourcesFound)
Listing 6.22: Konstruktor SimpleMVSKMetadata.java
Nach Maßgabe des Betreuers wird dieser ADT in der prototypischen Implementierung
keine Anwendung finden, da auf die Implementierung der Komponenten BS und TA
verzichtet wird. Somit beginnt der Analyse-Ablauf in der prototypischen Implementierung mit dem Selektieren der Trainingsdaten und Basisklassifikatoren. Der Prozess der
Suche nach vorhandenen Ressourcen wird übersprungen. Die Aufgaben der Ausführung
des Analyse-Ablaufes werden von der message-driven Bean MVSK übernommen, die in
Abschnitt 6.2 ausführlich dargestellt wird.
129
130
Verwertungs-Komponente Die Verwertungs-Komponente steuert die weitere Verarbeitung des durch den Analyse-Ablauf erzeugten ContentResource-Objektes. Dazu
wird eine String-Repräsentation des Wertes der weiteren Verwendung sowie ein Objekt zum Zugriff auf die Datensenke, in der das erzeugte Objekt gespeichert werden soll,
verwendet.
Abbildung 6.11 zeigt die Klasse SimpleVKMetadata, die das Interface
VKMetadata repräsentiert. Die Klasse setzt die Speicherung der Metadaten zum
Zugriff auf die Datensenke sowie den String, der die Verwertung indiziert, um.
redicat::metadata::SimpleContentResourceLocation
SimpleContentResourceLocation()
getDataSourceMD()
getUserName()
getUserPasswd()
setDataSourceMD()
setUserName()
setUserPasswd()
<<interface>>
<<interface>>
VKMetadata
<<interface>>
<<use>>
<<use>>
getUtilisation()
getDataSourceMD()
getComponentName()
setUtilisation()
setDataSourceMD()
setComponentName()
getSinkLocation()
setSinkLocation()
<<interface>>
<<interface>>
redicat::metadata::ResultDataSetLocation
setUtilisation()
getDataSourceMD()
getDataSourceMD()
getComponentName()
SimpleVKMetadata()
getUserName()
getUserName()
setComponentName()
getSinkLocation()
getUserPassword()
getUserPasswd()
setSinkLocation()
setDataSourceMD()
setDataSourceMD()
setUserName()
setUserName()
setUserPassword()
setUserPasswd()
SimpleVKMetadata
redicat::metadata::SimpleComponentAddress
getUtilisation()
redicat::metadata::SimpleClassifierLocation
redicat::metadata::SimpleResultDataSetLocation
getDataSourceMD()
getDataSourceMD()
getUserName()
getUserName()
getUserPassword()
getUserPasswd()
setDataSourceMD()
setDataSourceMD()
setUserName()
setUserName()
setUserPassword()
setUserPasswd()
Komponente
der Metadaten
zur Steuerung
der Verwertungs-
VKMetadata (Interface)
Beschreibung Modelliert einen abstrakten Datentyp zur Angabe der Verwertung
des durch einen Analyse-Ablauf erzeugten ContentResource-Objektes.
Dazu werden ein String-Attribut zur Bestimmung der Verwertung der erzeugten Ressource sowie Metadaten zum Zugriff auf eine Datensenke, in der die
erzeugte Ressource gespeichert werden soll, vorgesehen.
Superinterfaces Subinterfaces Implementierungen SimpleVKMetadata.java
• ContentResourceLocation getSinkLocation(): gibt die
Metadaten zum Zugriff auf die Datensenke zurück, in der die durch den
Analyse-Ablauf erzeugte Ressource gespeichert werden soll.
• void setSinkLocation(
ContentResourceLocation sinkLocation): setzt
die Metadaten zum Zugriff auf die Datensenke, in der die erzeugte Ressource gespeichert werden soll, auf den Parameter sinkLocation.
130
131
• java.lang.String getUtilisation(): gibt die StringRepräsentation des durch einen Analyse-Ablauf erzeugten Objektes
zurück.
• void setUtilisation(
java.lang.String utilisation): setzt die StringRepräsentation des durch einen Analyse-Ablauf erzeugten Objektes auf
den Parameter utilisation.
SimpleVKMetadata (Class)
Beschreibung Diese Klasse stellt eine einfache Implementierung des Interfaces VKMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces VKMetadata.java
• ContentResourceLocation sinkLocation: die Metadaten
zum Zugriff auf die Datensenke, in der die durch den Analyse-Ablauf
erzeugte Ressource gespeichert werden soll.
• java.lang.String utilisation: eine String-Repräsentation der
möglichen Verwertungen eines durch einen Analyse-Ablauf erzeugten
ContentResource-Objektes. Mögliche Werte sind:
– store zur Speicherung in einer Datensenke
– visualize zur Visualisierung gegenüber dem Benutzer
– both zur Speicherung in einer Datensenke und gleichzeitiger Visualisierung gegenüber einem Benutzer.
1
2
3
public SimpleVKMetadata(
java.lang.String utilisation,
ContentResourceLocation sinkLocation)
Listing 6.23: Konstruktor SimpleVKMetadata.java
6.1.3. Interfaces und prototypische Implementierungen zur
Parametrisierung der Analyse-Algorithmen
Im Rahmen des ReKlaMe-Projektes sind verschiedene Analyse-Abläufe möglich, die unterschiedliche Komponenten mit unterschiedlicher Funktionalität einbinden. Einige dieser Komponenten bilden Analyse-Algorithmen ab, deren Ablauf parametrisierbar ist. Um die Parametrisierung dieser Algorithmen zu ermöglichen, werden verschiedene abstrakte Datentypen entworfen. Diese seien im Folgenden vorgestellt:
(Inkrementelle) Induktions-Komponente Diese Komponente implementiert einen (inkrementellen) Induktions-Algorithmus. Je nach Ausführung des implementierten Algorithmus existiert die Möglichkeit der Parameterübergabe. Das Interface, das diesen
Datentyp umsetzt, sei mit InductionMetadata bezeichnet und in Abbildung 6.12
zusammen mit der implementierenden Klasse SimpleInductionMetadata dargestellt. Die Parameter können über den abstrakten Datentyp ParameterSet als
Property in einer Liste des Datentyps java.util.Properties angegeben werden. Eine Property besteht immer aus einem Paar eines Schlüsselwortes und dessen
131
132
Wertes. Somit können über die Schlüsselworte Parameternamen und über die Werte der
Schlüsselworte die Werte der Parameter übergeben werden.
Klassifikations-Komponente Analog zur Induktions-Komponente kann auch der
in der Klassifikations-Komponente implementierte Algorithmus potentiell parametrisiert werden. Um dies zu ermöglichen, wird ein abstrakter Datentyp in
Form eines Interfaces ClassificationMetadata eingeführt, das analog zu
InductionMetadata aufgebaut und ebenfalls zusammen mit seiner Implementierung SimpleClassificationMetadata in Abbildung 6.12 dargestellt ist.
Komponenten zur Durchführung der Klassifikator-Wartung Auch die KlassifikatorWartung, an der verschiedene Komponenten partizipieren, muss parametrisiert werden. Die Parametrisierung der Algorithmen erfolgt analog zu InductionMetadata
und ClassificationMetadata durch ein ParameterSet. Das Interface
MaintenanceMetadata, das die Metadaten zur Steuerung der an dem WartungsAblauf beteiligten Komponenten abbildet, ist zusammen mit der implementierenden
Klasse SimpleMaintenanceMetadata in Abbildung 6.12 dargestellt. Die einfaredicat::metadata::SimpleParameterSet
SimpleParameterSet()
getParameters()
setParameters()
<<interface>>
redicat::metadata::ParameterSet
getParameters()
setParameters()
<<use>>
<<use>>
<<use>>
<<interface>>
<<interface>>
ClassificationMetadata
MaintenanceMetadata
getParams()
getParams()
setParams()
setParams()
<<use>>
<<interface>>
InductionMetadata
<<use>>
getParams()
setParams()
<<use>>
SimpleClassificationMetadata
SimpleMaintenanceMetadata
SimpleInductionMetadata
SimpleClassificationMetadata()
SimpleMaintenanceMetadata()
SimpleInductionMetadata()
getParams()
getParams()
getParams()
setParams()
setParams()
setParams()
Abbildung 6.12.: Klassendiagramm der Klassen und Interfaces zur Repräsentation der ADT
zur Parametrisierung und Steuerung der Algorithmen, die durch Komponenten in der ReDiCAt-Architektur umgesetzt wurden
chen Implementierungen der Interfaces zur Parametrisierung der Analyse-Algorithmen
ermöglichen, wie auch schon die Implementierungen der Interfaces in Abschnitt 6.1.1,
die Demonstration der Funktionalität der Architektur. Es folgen die Beschreibungen der
Interfaces und Klassen zur Umsetzung der ADT, die die Algorithmen parametrisieren,
die in den Komponenten der ReDiCAt-Architektur eingebettet sind.
ClassificationMetadata (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Parametrisierung eines
Klassifikations-Algorithmus, der durch die Komponente KK der ReDiCAtArchitektur umgesetzt wird.
Superinterfaces -
132
133
Subinterfaces Implementierungen SimpleClassificationMetadata.java
• ParameterSet getParams(): gibt das Objekt ParameterSet
zurück, das den ADT repräsentiert, der die Parameter beinhaltet, die dem
Algorithmus übergeben werden sollen.
• void setParams(ParameterSet params): setzt das Objekt
ParameterSet, das den ADT repräsentiert, der die Parameter beinhaltet, die dem Algorithmus übergeben werden sollen, auf den Parameter
params.
InductionMetadata (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Parametrisierung eines
Klassifikator-Induktions-Algorithmus, der durch die Komponente (I)IK der
ReDiCAt-Architektur umgesetzt wird.
Superinterfaces Subinterfaces Implementierungen SimpleInductionMetadata.java
zurück, das den ADT repräsentiert, der die Parameter beinhaltet, die dem
Algorithmus übergeben werden sollen.
ParameterSet, das den ADT repräsentiert, der die Parameter beinhaltet, die dem Algorithmus übergeben werden sollen, auf den Parameter
params.
MaintenanceMetadata (Interface)
Beschreibung Modelliert eine Metadatenmenge zur Parametrisierung der Algorithmen zur Klassifikator-Wartung, die durch die Komponenten (I)IK und IVK
der ReDiCAt-Architektur umgesetzt werden.
Superinterfaces Subinterfaces Implementierungen SimpleMaintenanceMetadata.java
zurück, das den ADT repräsentiert, der die Parameter beinhaltet, die den
Algorithmen übergeben werden sollen.
ParameterSet, das den ADT repräsentiert, der die Parameter beinhaltet, die den Algorithmen übergeben werden sollen, auf den Parameter
params.
SimpleClassificationMetadata (Class)
ClassificationMetadata dar und dient dem Zwecke der Demonstration der Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces ClassificationMetadata.java
• ParameterSet params: das Objekt zur Repräsentation des ADT, der
die Parameter beinhaltet, die dem Algorithmus übergeben werden sollen.
133
134
1
2
public SimpleClassificationMetadata(
ParameterSet params)
Listing 6.24: Konstruktor SimpleClassificationMetadata.java
SimpleInductionMetadata (Class)
InductionMetadata dar und dient dem Zwecke der Demonstration der
Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces InductionMetadata.java
die Parameter beinhaltet, die dem Algorithmus übergeben werden sollen.
1
2
public SimpleInductionMetadata(
Listing 6.25: Konstruktor SimpleInductionMetadata.java
SimpleMaintenanceMetadata (Class)
MaintenanceMetadata dar und dient dem Zwecke der Demonstration der
Funktionsfähigkeit der ReDiCAt-Architektur.
Implementierte Interfaces MaintenanceMetadata.java
die Parameter beinhaltet, die den Algorithmen zur Wartung der Klassifikatoren übergeben werden sollen.
1
2
public SimpleMaintenanceMetadata(
Listing 6.26: Konstruktor SimpleMaintenanceMetadata.java
6.2. Objektorientiertes Design der Komponenten der
Architektur
Beim Design der Komponenten der Architektur wird die EJB-Architektur Verwendung finden.
Die Komponenten werden als Enterprise Beans (EB) umgesetzt, genauer als session beans (im
Folgenden als SB bezeichnet). Steuernde Komponenten wie z.B. die Komponente MVSK werden in Form von message-driven beans (folgend als MDB bezeichnet) implementiert. Datenoder Metadatensätze werden in Form von entity beans (fortan mit EB bezeichnet) umgesetzt.
134
6.2 O BJEKTORIENTIERTES D ESIGN DER KOMPONENTEN DER A RCHITEKTUR
Im Folgenden werden alle Komponenten, die in der prototypischen Implementierung der
ReDiCAt-Architektur implementiert werden, aufgeführt und in den Gesamtzusammenhang der
Architektur gebracht.
MVSK-Bean Die Komponente zur Metadatenverwaltung und Steuerung der Analyse-Abläufe
wird in Form einer MDB implementiert. Sie observiert eine Message-Queue, die
controlQueue. Die prototypische Implementierung dieser Komponente umfasst den
Teil der Analyse, der mit der Durchführung eines Analyse-Ablaufes betraut ist. Der Prozess der Suche nach vorhandenen Ressourcen wird nach Maßgabe des Betreuers dieser
Arbeit nicht umgesetzt.
Zur Initiierung eines Analyse-Ablaufes wird ein Objekt des Typs Task über eine Nachricht auf der controlQueue an die MVSK-MDB übergeben. Diese dekodiert die Nachricht und extrahiert das in der Nachricht enthaltene Task-Objekt in Abhängigkeit des
Wertes eines String-Parameters mit dem Namen Task, der zusätzlich mit der Nachricht
übergeben wurde. Dieser String-Parameter bestimmt den genauen Typ des übergebenen Task-Objektes und legt damit fest, ob dieses zu einem InductionTask-, einem
ClassificationTask- oder einem MaintenanceTask-Objekt gecastet wird.
Auf Basis des übergebenen String-Parameters und des dekodierten und gecasteten
Task-Objektes kann die Analyse durchgeführt werden. Die genauen Abläufe der möglichen Analysen sind in Abschnitt 6.3 dargestellt. Die MVSK-Bean sorgt weiter für die
Speicherung des Task-Objektes in einer EB, der TaskStorage-Bean. Diese EB ist
architekturweit zugreifbar, so dass jede Komponente zu jeder Zeit die Möglichkeit hat,
Daten aus dem Task-Objekt einzusehen.
In Abhängigkeit des auszuführenden Tasks wird das dekodierte und gecastete TaskObjekt an eine SB weitergegeben. Im Falle der Induktion ist dies die IMVK-SB, im Falle
der Klassifikation wird die AMVK-SB verwendet und im Falle der Klassifikator-Wartung
wird das Task-Objekt an die WMVK-SB übergeben. Je nach Art des auszuführenden
Tasks veranlasst die SB, an die das Task-Objekt übergeben wurde, die weiteren Schritte
zur Durchführung des Analyse-Ablaufes.
Hat eine der nachfolgenden SB die von ihr durchzuführende Aufgabe erledigt, so wird
erneut eine Nachricht an die MVSK-MDB geschickt, um die erfolgreiche Abarbeitung
der Teilaufgabe anzuzeigen bzw. zu bestätigen. Die Nachricht beinhaltet in einem solchen Falle einen String-Parameter mit der Bezeichnung resourceStored. Dieser Parameter weist auf die Speicherung einer Ressource hin, die im Rahmen der Ausführung der
Analyse selektiert wurde, und hat als Wert den Typ der Ressource, die gespeichert wurde. Dies kann z.B. ein Datensatz von Trainings- oder Instanzdaten sein, aber auch ein
Basisklassifikator. Je nach Wert dieses Parameters werden Nachrichten über die empfangene Bestätigung der erfolgreichen Beschaffung von Analyse-Ressourcen dem Benutzer
gegenüber ausgegeben.
Um die Ausführung weiterer Schritte im Rahmen der Abarbeitung eines AnalyseAblaufes zu veranlassen, können zusätzlich Nachrichten mit dem String-Parameter action übergeben werden. Zulässige Werte für diesen Parameter sind:
• executeClassifierCollection
• executeAnalysis
• AKMetadata
Der Wert executeClassifierCollection wird übergeben, wenn die Selektion
von Klassifikatoren durchgeführt werden soll, weil diese für den Fortlauf des AnalyseAblaufes benötigt werden. Der Wert executeAnalysis bewirkt den Aufruf der
135
135
136
Komponente, die den auszuführenden Analyse-Algorithmus implementiert. Im Falle einer Klassifikator-Induktion bewirkt dieser Wert also den Aufruf der Komponente, die
den Induktions-Algorithmus umsetzt, im Falle der Klassifikator-Anwendung den Aufruf der Komponente, die den Klassifikations-Algorithmus implementiert, usw. Der Wert
AKMetadata schließlich bewirkt die Erzeugung eines Metadatensatzes, der eine Ressource beschreibt, die durch einen Analyse-Ablauf erzeugt wurde. Dieser Metadatensatz
wird in ein globales Metadaten-Repository eingepflegt und steht für zukünftige AnalyseAblaufe potentiell zur Verfügung.
DSK-Bean, TD-Bean, ID-Bean Die DSK-SB ist mit der Selektion von Daten aus Datenquellen betraut. Anhand der ihr übergebenen Metadaten vom Typ DSKMetadata sucht
sie die Komponente auf, die die Datenquelle beinhaltet, aus der Daten selektiert werden sollen. Im Falle eines Induktions-Ablaufes werden aus der TD-SB Trainingsdaten
selektiert, im Falle des Anwendungs-Ablaufes aus der ID-SB Instanzdaten. Die Adresse der TD- oder ID-SB ist in DSKMetadata enthalten. Die selektierten Daten werden
in Form einer Nachricht an die analysisQueue weitergegeben. Diese wird von der
AnalysisControl-MDB observiert, deren Verhalten später beschrieben wird.
BSK-Bean, KR-Bean Die BSK-SB wird zur Selektion von Basisklassifikatoren aus einem
Klassifikator-Repository genutzt, welches durch die KR-SB implementiert wird. Sie bekommt einen Metadatensatz vom Typ BSKMetadata übergeben, anhand dessen sie die
Komponente KR auffinden kann, um eine Menge von Basisklassifikatoren zu selektieren. Die selektierten Basisklassifikatoren werden, analog zum Verhalten der DSK-SB, in
Form einer Nachricht an die analysisQueue gesendet.
IVK-Bean, GU-Bean Die IVK-SB dient der Invalidierung von Klassifikatoren im Rahmen
des Analyse-Ablaufes einer Klassifikator-Wartung. Sie erhält einen Metadatensatz vom
Typ IVKMetadata, der die Metadaten zur Selektion des zu invalidierenden Klassifikators beinhaltet. Dieser wird aus dem Klassifikator-Repository selektiert und durch
das Setzen eines Zeitstempels für das Transaktionszeitende als invalid gekennzeichnet. Der Zeitstempel wird von der GU-SB erzeugt, die als globale Uhr für die gesamte
ReDiCAt-Architektur dient. Nach Invalidierung des Klassifikators wird dieser wieder im
Klassifikator-Repository gespeichert.
IIK-Bean Die IIK-SB implementiert prototypisch einen Klassifikator-InduktionsAlgorithmus. Dazu benötigt sie eine Menge von Trainingsdaten und im Falle einer inkrementellen Induktion eine Menge von Basisklassifikatoren, die sie aus der
ContentResourceStorage-EB bezieht, sowie einen Metadatensatz vom Typ
InductionMetadata zur potentiellen Parametrisierung des Induktionsvorganges.
Anhand dieser Eingaben induziert die IIK-SB einen neuen Klassifikator vom Typ
SimpleClassifier. Die Induktion wird nicht semantisch vollständig und korrekt
implementiert, sondern in Form eines prototypischen Induktions-Algorithmus, der einen
willkürlichen Klassifikator erzeugt, sofern er die benötigten Eingaben in syntaktisch
korrekter Form bekommt. Die Induktion erfolgt ohne Berücksichtigung der Semantik
der Eingabedaten und Basisklassifikatoren. Der prototypisch induzierte, neue Klassifikator wird anschließend in Form einer Nachricht an die utilisationQueue gesendet,
die von der VKControl-MDB observiert wird. Das Verhalten der VKControl-MDB
wird später beschrieben.
KK-Bean Die KK-SB stellt eine prototypische Implementierung eines KlassifikationsAlgorithmus dar. Sie erzeugt anhand der Eingabedaten, die aus einem Instanzdatensatz und einem darauf anzuwendenden Basisklassifikator bestehen,
ein Klassifikationsergebnis. Parametrisierende Metadaten werden in Form eines ADT ClassificationMetadata übergeben. Sie liest die in der
136
ContentResourceStorage-EB zwischengespeicherten Instanzdaten und den anzuwendenden Klassifikator ein und erzeugt aus diesen ohne Beachtung deren Semantik
willkürlich ein Klassifikationsergebnis. Dieses wird, analog zum Vorgehen der IIK-SB,
in Form einer Nachricht an die utilisationQueue gesendet.
ML-Bean Die ML-SB implementiert einen prototypischen Meta-Lern-Algorithmus. Dieser
wird durch die Übergabe eines Metadatensatzes vom Typ InductionMetadata
parametrisiert. Analog zur IIK-SB liest die ML-SB die Klassifikatoren aus der
ContentResourceStorage-EB aus und erzeugt ohne Beachtung der Semantik der
Basisklassifikatoren ein willkürliches, globales Modell. Dieses wird, analog zum Vorgehen der IIK-SB und der KK-SB, in Form einer Nachricht an die utilisationQueue
gesendet.
SGAK-Bean, DBAGK-Bean Die SGAK-SB ist Teil der Algorithmik, die aus einem Klassifikator über die Ableitung von Selection Graphs und deren Wandlung zu Datenbankabfragen einen alternativen Weg der Klassifikation darstellt. Die SGAK-SB
wird über einen ADT des Typs DBAGKMetadata parametrisiert und liest aus der
ContentResourceStorage-EB den benötigten Klassifikator aus. Dieser wird auf
Basis eines prototypisch implementierten Algorithmus willkürlich zu Selection Graphs
verarbeitet, die der DBAGK-SB übergeben werden. Diese wandelt die Selection Graphs
ebenfalls prototypisch zu Datenbank-Abfragen und wendet diese auf die Komponente ID-SB an, die die Instanzdaten beinhaltet. Die Adresse der ID-SB entnimmt sie den
Metadaten, die der SGAK-SB übergeben und an sie weitergereicht wurden. Die Ergebnisse der einzelnen Anfragen werden zu einem Gesamt-Klassifikationsergebnis verarbeitet
und, analog zum Vorgehen der IIK-SB, der KK-SB und der ML-SB in Form einer Nachricht an die utilisationQueue gesendet.
AnalysisControl-Bean Die AnalysisControl-MDB dient der Zwischenspeicherung
von Ressourcen, die durch andere Komponenten wie beispielsweise die DSK-SB oder
die BSK-SB aus verschiedenen Datenquellen selektiert wurden. Sie bekommt eine
Ressource per Nachricht übergeben, extrahiert diese aus der Nachricht und speichert
sie in Abhängigkeit des Typs in der ContentResourceStorage-EB. Nach erfolgreicher Speicherung sendet die AnalysisControl-MDB eine Nachricht an die
controlQueue, die als Bestätigung der erfolgreichen Ausführung einer RessourcenSelektion dient. Diese Nachricht wird mit einer String-Property resourceStored versehen, die in Abhängigkeit des Typs der zu speichernden Ressource die Werte
trainingsdata, instancedata oder classifierset annehmen kann. Anhand dieser String-Property kann die MDB, die die controlQueue observiert, entsprechend auf das Ereignis der Ressourcenspeicherung reagieren. In der prototypischen
Implementierung der ReDiCAt-Architektur wird sich die Reaktion auf die Ausgabe einer
bestätigenden Nachricht beschränken.
VK-Bean, KE-Bean, AK-Bean, MetadataRepository-Bean Die VK-SB ist mit der Verarbeitung des durch den Analyse-Ablauf erzeugten ContentResource-Objektes betraut. Anhand der Metadaten, die in Form eines ADT vom Typ VKMetadata übergeben
werden, kann die weitere Verarbeitung der erzeugten Ressource veranlasst werden. So
beinhalten die Metadaten ein String-Objekt, welches die Art der Verarbeitung bestimmt. Mögliche Werte sind hier store zur Speicherung der Ressource, visualize
zur Visualisierung gegenüber einem Benutzer sowie both, um sowohl eine Speicherung der Ressource als auch deren Visualisierung zu veranlassen. Im Falle der Speicherung werden Metadaten zum Zugriff auf die Datensenke benötigt, in der die Ressource gespeichert werden soll. Dazu enthalten die Metadaten vom Typ VKMetadata
ein ADT des Typs ContentResourceLocation, welches die Adresse der Komponente, die die Datensenke beherbergt, sowie einen Benutzernamen und ein Passwort
137
137
138
beinhaltet. Die Datensenke wird in Form der KE-SB prototypisch implementiert. Nach
erfolgter Speicherung und/oder Visualisierung erfolgt der Aufruf der AktualisierungsKomponente AK, die ebenfalls als SB implementiert wird und auf Basis der durch den
Analyse-Ablauf erzeugten, neuen Ressource einen Metadatensatz erzeugt und in ein globales Metadaten-Repository einpflegt, der die neu erzeugte Ressource beschreibt und referenzierbar macht. Anhand dieses Metadatensatzes kann die neu erzeugte Ressource im
Rahmen späterer Analyse-Abläufe aufgefunden und in einen Analyse-Prozess mit eingebunden werden. Zu diesen Metadaten, die in einem globalen Metadaten-Repository
gespeichert werden, zählen verschiedene Informationen:
• ein String-Objekt, welches den Typ der neu erzeugten Ressource repräsentiert. Erlaubte Werte sind classifier, globalModel oder
classificationResult.
• einen ADT zur Repräsentation der Metadaten zum Zugriff auf die Datensenke, in der die neu erzeugte Ressource gespeichert wurde, in Form eines
ContentResourceLocation-Objektes. Anhand dieser Metadaten kann die
Ressource später aus der Datenquelle extrahiert werden.
• ein String-Objekt, das eine Beschreibung der neu erzeugten Ressource beinhaltet. Diese kann einem Benutzer präsentiert werden, und dieser kann auf Basis dieser Beschreibung die Nützlichkeit der Ressource für einen eigenen Analyse-Ablauf
ermessen.
• einen ADT zur Repräsentation der Metadaten zum Zugriff auf die Datenquelle, die
die Grundlage der Erzeugung des neuen ContentResource-Objektes darstellte, also z.B. eine Datenquelle, die einen Klassifikator beinhaltet, anhand dessen
ein Klassifikationsergebnis erzeugt wurde. Diese Information kann sinnvoll sein,
wenn ein Benutzer sehen möchte, ob bereits Ergebnisse existieren, die denen einer
geplanten Analyse entsprächen.
Das Metadaten-Repository wird in der prototypischen Implementierung nicht in Form
eines klassischen Repositories als Datenbank oder DWH implementiert. Anstelle dessen werden die Metadatensätze, die eine von der ReDiCAt-Architektur erzeugte Ressource beschreiben, in Form von Entity-Beans vom Typ MetadataRepository implementiert, die anhand ihrer Attribute auffindbar sind. So lässt sich nach Teilen der
Beschreibung oder aber nach dem Ort der Speicherung einer Ressource suchen. Eine
entsprechende Such-Komponente, wie sie in der Planung des Ausführungsmodelles in
Abschnitt 5.1 aufgezeigt wird, erfolgt nach Maßgabe des Betreuers im Rahmen der prototypischen Implementierung nicht. Die MetadataRepository-EB implementiert
die Suchbarkeit der Felder hingegen auch in der prototypischen Implementierung der
ReDiCAt-Architektur.
IMVK-Bean Die IMVK-SB steuert die Abläufe, die zur Durchführung einer KlassifikatorInduktion erforderlich sind.
In Abhängigkeit des auszuführenden Induktions-Tasks (ci, ici oder ml) werden verschiedene Prozesse initiiert. So wird im Falle eines ci oder ici-Tasks zunächst die Selektion der zugrunde liegenden Trainingsdaten mittels der DSK-SB initiiert. Nach erfolgter Trainingsdatenselektion und Versendung der selektierten Daten mittels einer Nachricht an die analysisQueue wird eine Nachricht mit der String-Property action an
die controlQueue gesendet, die den Wert executeClassifierCollection
aufweist. Im Falle eines ml-Tasks ist die Datenselektion nicht notwendig, so dass direkt
eine Nachricht an die controlQueue gesendet werden kann, die eine KlassifikatorSelektion initiiert.
138
Anschließend wird die Klassifikator-Selektion mittels der BSK-SB durchgeführt. Dazu werden die im InductionTask-Objekt enthaltenen Adressen der BSK-Adressen
durchgegangen und die entsprechenden Basisklassifikatoren werden aus ihren Datenquellen selektiert. Die selektierten Klassifikatoren werden in Form einer Nachricht an
die analysisQueue zur weiteren Verarbeitung gesendet. Weiter wird eine Nachricht an die controlQueue gesendet, die die String-Property action mit dem Wert
executeAnalysis beinhaltet. Diese Nachricht sorgt für die Initiierung des AnalyseAlgorithmus, der eine neue Ressource erzeugt.
Die Durchführung dieses Analyse-Algorithmus wird erneut durch den auszuführenden
Induktions-Task bestimmt. Zunächst wird die Komponente spezifiziert, die den Algorithmus implementiert. Dies ist im Falle eines ci-Tasks oder eines ici-Tasks eine IIK-SB,
im Falle eines ml-Tasks handelt es sich um eine ML-SB. Dann erfolgt der Aufruf der Methode der spezifizierten Analyse-Komponente, die den Algorithmus ausführt.
Ein genaues Diagramm der an einem Induktions-Ablauf beteiligten Komponenten und
Methoden wird in Abschnitt 6.3 gegeben.
AMVK-Bean Die AMVK-SB steuert die Prozesse, die zur Durchführung eines AnalyseAblaufes einer Klassifikator-Anwendung benötigt werden. Hier muss zwischen dem naiven Ansatz der Klassifikator-Anwendung und dem auf Selection-Graph-Ableitung basierenden Ablauf unterschieden werden.
naiver Ansatz: Im Falle eines naiven Ansatzes wird zunächst mittels einer DSK-SB
die Instanzdatenmenge selektiert, die klassifiziert werden soll. Diese Datenmenge wird an die analysisQueue in Form einer Nachricht gesendet, um deren
weitere Verarbeitung zu veranlassen. Anschließend wird eine Nachricht an die
controlQueue gesendet, die mittels der String-Property action, die den Wert
executeClassifierCollection trägt, die Selektion des Klassifikators initiiert, der die Grundlage der Klassifikation darstellt.
Dann wird der Klassifikator über eine BSK-SB selektiert und ebenfalls an die
analysisQueue gesendet. Durch eine Nachricht mit der String-Property action
und dem Wert executeAnalysis, die an die controlQueue gesendet wird,
wird die Ausführung der Klassifikation initiiert.
Dazu wird eine KK-SB spezifiziert, die auf die zuvor selektierten Daten zugreifen
kann und die Klassifikation durchführt.
Selection-Graph-basierter Ansatz: Im Falle der Klassifikation durch SelectionGraph-Ableitung wird in einem ersten Schritt die Klassifikator-Selektion durch eine BSK-SB aufgerufen. Dies geschieht analog zum naiven Klassifikations-Ansatz
über die Versendung einer Nachricht an die controlQueue, die eine StringProperty action mit dem Wert executeClassifierCollection enthält.
Der Klassifikator wird anschließend durch eine SGAK-SB zu einer Menge von Selection Graphs gewandelt, die dann zu Datenbank-Abfragen umgesetzt und auf die
Datenquelle, die die Instanzdaten beinhaltet, angewendet werden. Diese prototypisch umgesetzten Wandlungen wurden bereits zuvor beschrieben.
Auch hier wird ein genaues Diagramm der an einem Klassifikations-Ablauf beteiligten Komponenten und Methoden in Abschnitt 6.3 aufgezeigt.
WMVK-Bean Die WMVK-SB steuert die Prozesse, die am Ablauf der Wartung eines Klassifikators beteiligt sind. Dazu zählt die Invalidierung des zu wartenden Klassifikators und
dessen Speicherung sowie die neue Induktion des zu wartenden Klassifikators, ebenfalls
gefolgt von dessen Speicherung.
139
139
140
Der Ablauf gestaltet sich wie folgt: Zunächst wird durch die MVSK-MDB eine Invalidierung des zu wartenden Klassifikators durchgeführt. Dazu wird eine InvalidierungsKomponente IVK-SB spezifiziert, die einen Klassifikator übergeben bekommt, den sie
anhand eines globalen Zeitstempels von der GU-SB als invalid markiert und anschließend wieder im von der KR-SB umgesetzten, prototypischen Klassifikator-Repository
speichert.
Nach erfolgter Invalidierung verläuft der weitere Prozess der Klassifikator-Wartung analog zur Klassifikator-Induktion, die bereits zuvor beschrieben wurde. In der prototypischen Implementierung wird der Vorgang der Wartung eines beliebigen Klassifikators
auf die Wartung eines inkrementell induzierten Klassifikators eingeschränkt. Dieser Vorgang steht stellvertretend für die Wartungsvorgänge eines einfach induzierten oder durch
einen Meta-Lern-Prozess erzeugten Klassifikators.
6.3. Beschreibung der Methodenaufrufe zur Durchführung
der Analyse-Abläufe
Nachdem in Abschnitt 6.2 die Komponenten im Einzelnen in ihrer Funktionalität vorgestellt wurden, erfolgt nun die Darstellung der Verbindungen dieser in Form von SequenzDiagrammen. Zu den Analyse-Abläufen, die in der prototypischen Implementierung umgesetzt
werden, wird die Abfolge der Methodenaufrufe dargestellt. Somit können die Komponenten
miteinander in Verbindung gebracht werden, und die Vorgänge, die während der Ausführung
eines Analyse-Ablaufes ablaufen, können leichter nachvollzogen werden.
Die Sequenzen der Methodenaufrufe für die Umsetzung der Analyse-Abläufe sind in den folgenden Abschnitten in verschiedenen Abbildungen in Form von Sequenz-Diagrammen dargestellt. Um die Übersichtlichkeit der Sequenz-Diagramme zu verbessern, werden z.T. verschiedene Methoden untereinander dargestellt, und es wird auf die Angabe der Parameter verzichtet,
die den aufgerufenen Methoden übergeben werden.
6.3.1. Ablauf der einfachen und inkrementellen Klassifikator-Induktion
Anhand des Sequenz-Diagrammes in Abbildung 6.13 ist der Verlauf der Methodenaufrufe und
damit die Verbindung der Komponenten der ReDiCAt-Architektur untereinander zur Umsetzung des Analyse-Ablaufes der einfachen und inkrementellen Klassifikator-Induktion einzusehen. Der Unterschied zwischen der einfachen und der inkrementellen Induktion eines Klassifikators besteht in der prototypischen Implementierung darin, dass nur während des Ablaufes der
inkrementellen Induktion Basisklassifikatoren durch die BSK-SB selektiert werden. Im Falle
der einfachen Induktion wird die BSK-SB zwar aufgerufen, jedoch werden keine Klassifikatoren selektiert.
Exemplarisch für den Ablauf einer Klassifikator-Induktion sei im Folgenden der Verlauf der
Methodenaufrufe aufgezeigt, wie er im Falle der inkrementellen Induktion ablaufen wird, auf
die Darstellung der einfachen Induktion wird hier verzichtet, da sie mit Ausnahme der zuvor
erwähnten, fehlenden Basisklassifikator-Selektion analog verläuft.
Über die Client-Applikation JavaUserInterface wird ein Analyse-Ablauf zur inkrementellen Klassifikator-Induktion initiiert. Dies geschieht, indem über die controlQueue
der MVSK-MDB eine Nachricht mit einem SimpleInductionTask-Objekt und einer
String-Property Task mit dem Wert ci übergeben wird. Die onMessage()-Methode der
MVSK-MDB speichert das Task-Objekt durch Aufruf der Methode setTask() einer
140
6.3 B ESCHREIBUNG DER M ETHODENAUFRUFE ZUR D URCHF ÜHRUNG DER A NALYSE -A BL ÄUFE
TaskStorage-EB in einer Instanz mit der ID 1, über die diese architekturweit referenzierbar ist. Anschließend wird von MVSK-MDB die Methode executeDataCollection()
der IMVK-SB aufgerufen. Diese ruft die Methode deliverDataSet() einer DSK-SB
auf, die für die Selektion einer Trainingsdatenmenge verantwortlich ist. Die Selektion der
Trainingsdatenmenge erfolgt durch den Aufruf der Methode getTrainingsData() der
TD-SB. Die selektierten Daten werden zusammen mit einer String-Property dataType und
deren Wert trainingsdata in Form einer Nachricht an die analysisQueue gesendet, die von der AnalysisControl-MDB observiert wird. Die onMessage()-Methode
der AnalysisControl-MDB ruft ihrerseits die Methode setSelectedDataSet() einer EB-Instanz vom Typ ContentResourceStorage mit der ID 1 auf, um in dieser
EB die selektierten Daten zwischenzuspeichern. Um die erfolgreiche Zwischenspeicherung
der Trainingsdaten an die MVSK-MDB zu melden, sendet die onMessage()-Methode der
ContentResourceStorage-EB anschließend eine Nachricht mit der String-Property resourceStored und dem Wert trainingsdata an die controlQueue.
Nachdem die DSK-SB die Trainingsdaten als Nachricht an die analysisQueue geschickt hat, schickt sie eine weitere Nachricht mit der String-Property action und dem
Wert executeClassifierCollection an die controlQueue, um die Selektion
der Klassifikatoren durchzuführen, die im SimpleInductionTask-Objekt aufgeführt
sind. Die onMessage()-Methode der MVSK-MDB ruft nach Erhalt dieser Nachricht
die Methode executeClassifierCollection() der IMVK-SB auf, die ihrerseits
die Methode deliverClassifierSet() einer BSK-SB aufruft. Die BSK-SB lokalisiert die Komponenten des Typs KR-SB, die die Klassifikatoren speichern, die für die
inkrementelle Induktion benötigt werden, und ruft für jeden zu selektierenden Klassifikator die Methode getClassifier() der entsprechenden KR-SB auf. Die auf diese Weise selektierten Basisklassifikatoren werden anschließend als Vector-Objekt in
Form einer Nachricht mit der String-Property dataType und dem Wert classifierset
an die analysisQueue gesendet. Nach Empfang der Nachricht ruft die Methode
onMessage() der AnalysisControl-MDB die Methode setClassifier() der
ContentResourceStorage-EB-Instanz mit der ID 1 auf, um die Basisklassifikatoren
zwischenzuspeichern. Analog zum Vorgehen nach der Speicherung der Trainingsdatenmenge wird auch nach der Speicherung der Basisklassifikatoren eine Nachricht mit der StringProperty resourceStored und dem Wert classifierset an die controlQueue gesendet.
Analog zum Verhalten der DSK-SB sendet auch die BSK-SB nach der Versendung der
Basisklassifikatoren eine weitere Nachricht an die controlQueue, die in diesem Fall
eine String-Property action mit dem Wert executeAnalysis beinhaltet. Der Empfang dieser Nachricht veranlasst die onMessage()-Methode der MVSK-MDB zum Aufruf der Methode executeAnalysisTask() der IMVK-SB. Diese ruft die Methode
induceClassifier() einer Instanz derIIK-EB auf. Die IIK-SB ruft die zwischengespeicherten Trainingsdaten über die Methode getSelectedDataSet() und die zwischengespeicherten Basisklassifikatoren über die Methode getClassifierSet() der Instanz
der ContentResourceStorage-EB mit der ID 1 ab und versendet den daraus induzierten, neuen Klassifikator in Form einer Nachricht mit der String-Property contentResourceType
und dem Wert classifier an die utilisationQueue, die von der VKControl-MDB
observiert wird.
Der Empfang dieser Nachricht veranlasst die onMessage()-Methode der VKControlMDB, die Methode utiliseResource() einer VKBean-SB-Instanz aufzurufen, nachdem sie sich das SimpleInductionTask-Objekt mit den Metadaten des auszuführenden Analyse-Ablaufes über die Methode getTask() der Instanz einer TaskStorage-EB
mit der ID 1 aufgerufen hat. Auch die VKBean holt sich auf diese Weise das Task-Objekt
und verwertet den per Nachricht übergebenen, neu erzeugten Klassifikator in Abhängigkeit
141
141
142
der im Task-Objekt angegebenen Metadaten. Sofern der Klassifikator gespeichert werden
soll, lokalisiert die VK-SB die entsprechende Instanz der KR-SB und ruft deren Methode
setClassifier() auf, um den Klassifikator zu speichern.
Nach der Verwertung des erzeugten Klassifikators wird eine Nachricht mit einer StringProperty action und dem Wert AKMetadata sowie einem Metadaten-Objekt vom Typ
AKMetadata, welches Metadaten zur Beschreibung des neu erzeugten Klassifikators
enthält und von der VK-SB erzeugt wurde, an die controlQueue gesendet. Die Methode onMessage() der MVSK-MDB reagiert auf den Empfang der Nachricht, indem sie
zunächst die zur Zwischenspeicherung des Task-Objektes und der ContentResourceObjekte, die zur Induktion benötigt wurden, löscht. Dies geschieht durch die Aufrufe
der Methoden deleteTask() bzw. deleteContentResourceStorageBean() der
TaskStorage-EB bzw. der ContentResourceStorage-EB mit der ID 1. Anschließend ruft sie die Methode storeContentResourceMetadata() der AK-Bean auf, um
die erzeugten Metadaten über den neuen Klassifikator im Metadaten-Repository zu speichern,
welches in Form einer Menge von EBs vom Typ MetadataRepository prototypisch implementiert wird. Um eine solche Bean mit den Metadaten über den neuen Klassifikator zu
füllen, werden nacheinander die Methoden setType(), setDataSourceLocation(),
setDescription() und setRepositoryLocation() einer neuen Instanz einer
MetadataRepository-EB aufgerufen. Somit sind die beschreibenden Metadaten über den
neu erzeugten Klassifikator in das Metadaten-Repository eingefügt, und der Analyse-Ablauf
der inkrementellen Klassifikator-Induktion ist vollständig ausgeführt und terminiert.
142
Abbildung 6.13.: Sequenz-Diagramm der Methodenaufrufe zur Durchführung einer einfachen
Klassifikator-Induktion
143
143
144
6.3.2. Ablauf des Meta-Lernens
Die Verbindungen der Komponenten untereinander und die Methodenaufrufe zur
Durchführung eines Meta-Lern-Analyse-Ablaufes sind in Abbildung 6.14 in Form eines
Sequenz-Diagrammes dargestellt. Die dargestellten Abläufe gleichen in weiten Teilen denen,
die in Abschnitt 6.3.1 ausführlich erläutert wurden. Es lassen sich jedoch auch Unterschiede
beobachten.
Ein erster Unterschied zeigt sich in der Übergabe des Wertes der String-Property Task, die von
der Client-Applikation JavaUserInterface übergeben wird und den Wert ml aufweist,
der einen Meta-Lern-Vorgang initiiert.
Ein zweiter Unterschied besteht in dem nicht vorhandenen Ablauf der TrainingsdatenSelektion, da diese für den Meta-Lern-Vorgang nicht benötigt werden. So wird nach
Speicherung des SimpleInductionTask-Objektes über die Methode setTask() der
TaskStorage-EB-Instanz mit der ID 1 unter Umgehung des Aufrufes der Methode
executeDataCollection() die Methode executeClassifierCollection()
der IMVK-SB direkt aufgerufen.
Der dritte Unterschied zeigt sich im Aufruf der Komponente, die die Analyse durchführt.
Im Falle des Meta-Lern-Ablaufes wird die Methode executeMetaLearnTask() der
ML-SB durch die IMVK-SB aufgerufen, die anhand der Klassifikatoren, die in der Instanz
der ContentResourceStorage-EB mit der ID 1 gespeichert sind, durchgeführt wird.
Nachdem sich die ML-EB das aktuelle SimpleInductionTask-Objekt über die Methode getTask() der TaskStorage-EB mit der ID 1 geholt hat, sendet sie eine Nachricht
mit der String-Property contentResourceType und dem Wert globalModel sowie dem neu
erzeugten globalen Modell an die utilisationQueue, die von der VKControl-MDB observiert wird. Diese leitet, analog zum in Abschnitt 6.3.1 beschriebenen Vorgehen, die weitere
Verarbeitung des neu erzeugten globalen Modells ein.
Sonstige Methodenaufrufe verlaufen analog zu den in Abschnitt 6.3.1 beschriebenen Abläufen.
144
Abbildung 6.14.: Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines MetaLern-Prozesses
145
145
146
6.3.3. Ablauf der naiven Klassifikator-Anwendung
Auch die Sequenz der Methodenaufrufe während des Analyse-Ablaufes der naiven
Klassifikator-Anwendung, die in Abbildung 6.15 in Form eines Sequenz-Diagrammes dargestellt ist, zeigt analoge Vorgänge zum Ablauf der Klassifikator-Induktion.
Zunächst wird von der Client-Applikation JavaUserInterface eine Nachricht
mit der String-Property Task und dem Wert naive sowie einem ADT des Typs
SimpleClassificationTask, der die Metadaten zur Steuerung der naiven Klassifikation enthält, an die controlQueue gesendet, die von der MVSK-MDB observiert wird. Die
MVSK-MDB speichert das Metadaten-Objekt analog zum Vorgehen im Falle eines InduktionsAblaufes über den Aufruf der Methode setTask() der Instanz einer TaskStorage-EB
mit der ID 1. Anschließend wird die Methode executeDataCollection() der AMVKSB aufgerufen, um die Selektion der Instanzdatenmenge zu initiieren, die später klassifiziert
werden soll. Die aufgerufene Methode der AMVK-SB lokalisiert eine Instanz einer DSK-EB und
ruft auf dieser die Methode deliverDataSet() auf. Diese lokalisiert ihrerseits die passende Instanz einer ID-SB und ruft auf dieser die Methode getInstanceData() auf. Nach
Empfang der zu selektierenden Instanzdaten wird von der DSK-EB eine Nachricht mit den
selektierten Daten sowie einer String-Property dataType und dem Wert instancedata an
die analysisQueue gesendet. Die AnalysisControl-MDB speichert die per Nachricht
übergebenen Instanzdaten über den Aufruf der Methode setSelectedDataSet() der Instanz einer ContentResourceStorage-EB mit der ID 1. Nach erfolgreicher Speicherung
wird von der ContentResourceStorage-EB eine Nachricht mit einer String-Property
resourceStored und dem Wert instancedata an die controlQueue als Bestätigung der
erfolgreichen Speicherung gesendet.
Nachdem die DSK-SB die Nachricht mit den selektierten Daten an die analysisQueue
geschickt hat, schickt sie analog zum Vorgehen beim Ablauf der KlassifikatorInduktion eine weitere Nachricht mit der String-Property action und dem Wert
executeClassifierCollection an die controlQueue, um die Selektion des Klassifikators zu initiieren, der während des Vorganges der naiven Klassifikation angewendet
werden soll.
Empfängt die MVSK-MDB diese Nachricht, so ruft sie analog zum Vorgehen beim Ablauf der Klassifikator-Induktion die Methode executeClassifierCollection() der
AMVK-SB auf, um die Klassifikator-Selektion zu initiieren. Die AMVK-SB ruft weiter die
Methode deliverClassifierSet() einer BSK-SB auf, die wiederum die Methode getClassifier() einer KR-EB aufruft. Nach dem Empfang des zu selektierenden
Klassifikators sendet die BSK-SB eine Nachricht mit dem selektierten Klassifikator und
der String-Property dataType mit dem Wert classifierset an die analysisQueue,
woraufhin analog zur Klassifikator-Induktion der übergebene Klassifikator gespeichert und
die Kontrollkomponente über eine bestätigende Nachricht der erfolgreichen KlassifikatorZwischenspeicherung informiert wird.
Nach Versenden des Klassifikators schickt die BSK-SB eine weitere Nachricht mit der StringProperty action und dem Wert executeAnalysis an die controlQueue.
Nach dem Empfang dieser Nachricht wird von der MVSK-MDB die Methode
executeAnalysisTask() der AMVK-SB aufgerufen. Diese lokalisiert eine Instanz
der KK-SB und ruft deren Methode classifyDataSet() auf. Diese selektiert die
zwischengespeicherten Instanzdaten und den anzuwendenden Klassifikator über Aufrufe der Methoden getSelectedDataSet() bzw. getClassifierSet() der Instanz der ContentResourceStorage-EB mit der ID 1 und erzeugt prototypisch
ein syntaktisch korrektes Klassifikationsergebnis, welches in Form eines ADT vom
146
Typ SimpleResultDataSet umgesetzt wird. Dieses Klassifikationsergebnis wird
per Nachricht, die zusätzlich eine String-Property contentResourceType mit dem Wert
resultDataSet beinhaltet, an die utilisationQueue gesendet, die von der
VKControl-MDB observiert wird.
Empfängt diese die Nachricht, so wird das übergebene Klassifikationsergebnis über den Aufruf der Methode utiliseResource() an eine Instanz der VK-SB übergeben, die analog zum Vorgehen der Induktion eines Klassifikators für die Speicherung der übergebenen,
neu erzeugten Ressource sorgt. Dies geschieht in diesem Falle über den Aufruf der Methode
setResultDataSet() einer Instanz der KE-SB.
Nach erfolgter Speicherung des neu erzeugten Klassifikationsergebnisses wird, ebenfalls analog zum Vorgehen der Klassifikator-Induktion, eine Metadatenmenge generiert, die das neu
erzeugte Klassifikationsergebnis beschreibt und charakterisiert und im globalen MetadatenRepository gespeichert wird. Dies geschieht analog zum Ablauf der Klassifikation. Eine Beschreibung der Details dieser Vorgänge ist in Abschnitt 6.3.1 einzusehen.
147
147
148
Abbildung 6.15.: Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines AnalyseAblaufes der naiven Klassifikator-Anwendung
148
6.3.4. Ablauf der Klassifikation mittels Selection Graphs
Die Sequenz der Methodenaufrufe eines Analyse-Ablaufes der Klassifikation mittels der Ableitung einer Menge von Selection Graphs und deren Wandlung in Datenbank-Abfragen ist
in Abbildung 6.16 dargestellt. Dieser Ablauf wird im Folgenden ausführlich betrachtet und
erläutert.
Zum Start der Analyse wird von der Client-Applikation JavaUserInterface eine Nachricht mit einem SimpleClassificationTask-Objekt und einer String-Property Task mit
dem Wert sg an die controlQueue gesendet. Die MVSK-MDB, die die controlQueue
überwacht, extrahiert zunächst das Task-Objekt aus der Nachricht und speichert es mittels des
Methodenaufrufes setTask() der Instanz der TaskStorage-EB mit der ID 1. Anschließend wird die Methode executeDataCollection() einer AMVK-SB-Instanz aufgerufen.
Da bei diesem Analyse-Ablauf zu diesem Zeitpunkt keine Daten benötigt werden, erfolgt keine Selektion eines Datensatzes. Anstelle dessen wird eine Nachricht mit einer String-Property
action und dem Wert executeClassifierCollection aufgerufen.
Diese Nachricht bewirkt, dass durch die MVSK-MDB der Aufruf der Methode
executeClassifierCollection() einer Instanz der AMVK-SB erfolgt. Die aufgerufene Methode initiiert die Selektion des anzuwendenden Klassifikators durch den Aufruf der
Methode deliverClassifierSet() einer BSK-SB-Instanz. Diese fordert den zu selektierenden Klassifikator durch Aufruf der Methode getClassifier() der entsprechenden
KR-SB-Instanz an und liefert ihn an die BSK-SB zurück. Die BSK-SB erzeugt eine Nachricht,
die den Klassifikator sowie eine String-Property dataType mit dem Wert classifier beinhaltet, und sendet diese an die analysisQueue, die von der AnalysisControl-MDB
observiert wird.
Die AnalysisControl-MDB extrahiert den übergebenen Klassifikator und führt
die Zwischenspeicherung durch Aufruf der Methode setClassifierSet der Instanz der ContentResourceStorage-EB mit der ID 1 aus. Um die erfolgreiche Zwischenspeicherung an die kontrollierende Komponente zu bestätigen, sendet die
ContentResourceStorage-EB eine Nachricht mit der String-Property resourceStored
und dem Wert classifierset an die controlQueue. Der gespeicherte Klassifikator
dient als Grundlage der Klassifikation. Aus ihm werden in einem folgenden Schritt eine Menge
von Selection Graphs abgeleitet, die wiederum in Datenbankabfragen umgewandelt werden.
Anhand dieser Abfragen, die auf die Datenbank angewendet werden, die die Instanzdaten
enthält, wird die Klassifikation durchgeführt. Dazu sind die folgend beschriebenen Schritte
notwendig.
Nach Erhalt der Nachricht mit der String-Property action und dem Wert executeAnalysis,
die von der AMVK-SB gesendet wurde, nachdem der Klassifikator an die analysisQueue
gesendet wurde, erfolgen die Methodenaufrufe zur Wandlung des Klassifikators zu Selection
Graphs und deren weitere Anwendung, um eine Klassifikation durchzuführen. Dazu wird
zunächst von der MVSK-SB die Methode executeAnalysisTask() der AMVK-SB aufgerufen. Diese sorgt für den Aufruf der Methode executeSelectionGraphDerivation()
der SGAK-SB.
Diese Methode ist für die Ableitung der Selection Graphs aus dem Klassifikator zuständig.
Sie benötigt zunächst die Metadaten, die zum auszuführenden Ablauf erforderlich sind,
und holt sich diese über den Aufruf der Methode getTask() der TaskStorage-EBInstanz mit der ID 1. Anschließend wird der zwischengespeicherte Klassifikator geladen, indem die Methode getClassifierSet() der ContentResourceStorage-EB-Instanz
mit der ID 1 aufgerufen wird. Der Klassifikator wird prototypisch zu einer Menge von
Selection Graphs verarbeitet, die an die DBAGK-SB weitergegeben werden. Deren Methode executeQueryProcessing() wandelt prototypisch die Selection Graphs in eine
149
149
150
Menge von Datenbank-Abfragen und wendet diese der Reihe nach auf die Instanzdaten
an, indem sie die Abfragen einzeln über die Methode getInstanceData() der ID-SB
durchführt. Die zurückgegebenen Instanzen, die jeweils einer Zielklasse entsprechen, werden
zu einem ADT des Typs SimpleResultDataSet zusammengefügt und über eine Nachricht mit der String-Property contentResourceType mit dem Wert resultDataSet an die
utilisationQueue gesendet.
Das weitere Vorgehen erfolgt analog zum Vorgehen der naiven Klassifikation, die bereits
ausführlich in Abschnitt 6.3.3 beschrieben wurde. Zum weiteren Vorgehen zählen die Speicherung des erzeugten Klassifikationsergebnisses sowie die Erzeugung eines beschreibenden
Metadatensatzes und dessen Speicherung im globalen Metadaten-Repository.
150
Abbildung 6.16.: Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines AnalyseAblaufes der Klassifikation über Selection-Graph-Ableitung
151
151
152
6.3.5. Ablauf der Wartung eines inkrementell induzierten Klassifikators
Die Methodenaufrufe zur Durchführung des Analyse-Ablaufes der Klassifikator-Wartung, die
aus der Invalidierung eines Klassifikators und dessen erneuter Induktion anhand aktueller Trainingsdaten oder Basisklassifikatoren erfolgt, sind in Abbildung 6.17 aufgezeigt.
Der Ablauf der Wartung unterscheidet sich vom Ablauf einer einfachen Klassifikator-Induktion
in dem Punkt, dass vor der eigentlichen Neu-Induktion des zu wartenden Klassifikators der
alte Klassifikator invalidiert wird. Dies geschieht anhand eines Zeitstempels, der von einer
globalen Uhr angefordert wird und architekturweit gilt. Dieser Zeitstempel wird in das Feld
des Transaktionszeit-Endes des zu invalidierenden Klassifikators gesetzt. Die genaue Sequenz
der Methodenaufrufe sei folgend beschrieben.
Zunächst wird von der Client-Applikation JavaUserInterface eine Nachricht mit
der String-Property Task und dem Wert maintenance sowie einem ADT vom Typ
SimpleMaintenanceTask an die controlQueue gesendet. Die MVSK-MDB, die die
controlQueue überwacht, extrahiert das Task-Objekt und speichert dies über den Aufruf der Methode storeTask() einer Instanz der TaskStorage-EB mit der ID 1. Danach ruft die MVSK-MDB die Methode invalidateClassifier() der IVK-SB auf,
die für die Invalidierung des zu wartenden Klassifikators verantwortlich ist. Diese ruft die
Methode getGlobalTime() der GU-SB auf, die die architekturweit gültige, aktuelle Zeit
in Form eines java.sql.Timestamp-Objektes zurück gibt. Dieser Zeitstempel wird als
Transaktionszeit-Ende für den zu invalidierenden Klassifikator genutzt. Anschließend ruft die
IVK-SB die Methode setClassifier() der KR-SB auf, um den invalidierten Klassifikator
im Klassifikator-Repository zu speichern.
Der weitere Verlauf der Klassifikator-Wartung, die erneute Induktion des zu wartenden Klassifikators anhand aktueller Trainingsdaten und gegebenenfalls Basisklassifikatoren, erfolgt analog zum Vorgehen bei der Klassifikator-Induktion, die in Abschnitt 6.3.1 ausführlich beschrieben wurde.
152
Abbildung 6.17.: Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines AnalyseAblaufes der Klassifikator-Wartung
153
153
154
Dieses Kapitel zeigt den softwaretechnischen Entwurf der Komponenten der ReDiCAtArchitektur auf. Grundlage dieses Entwurfes bildet die in Kapitel 5 durchgeführte objektorientierte Analyse, die die Komponenten der Architektur vorgibt und auf dem in Kapitel 4
konzeptionierten Ausführungsmodell basiert.
Zunächst wurden in Abschnitt 6.1.1 die Metadaten-Formate definiert und entworfen, die
die atomaren Metadaten-Entitäten abbilden, die aus dem in Abschnitt 4 konzeptionierten
Ausführungsmodell abgeleitet werden können. Diese wurden auf JAVA-Interfaces abgebildet.
Die Metadaten-Entitäten umfassen beispielsweise ADT zur Repräsentation von Ressourcen
wie Klassifikatoren, Klassifikationsergebnisse oder selektierte Datenmengen, aber auch Metadaten über den gesamten Ablauf einer Analyse, die beispielsweise die Adressen der am
Analyse-Ablauf beteiligten Komponenten oder steuernde Metadaten für einzelne Komponenten beinhalten.
Zu jedem Interface erfolgte der Entwurf einer prototypischen Implementierung in Form einer JAVA-Klasse, deren Namen sich aus dem Namen des implementierten JAVA-Interfaces
ergänzt um das Namenspräfix Simple zusammensetzte. Die Darstellung der JAVA-Interfaces
und JAVA-Klassen wurde detailliert ausgeführt. So erfolgte die Darstellung der Beschreibung
des Interfaces, der in Beziehung zum Interface stehenden Super- und Sub-Interfaces sowie der
vorhandenen Implementierungen und umzusetzenden Methoden der Interfaces. In Bezug auf
die Darstellung der Klassen wurden die Beschreibung der Klasse, die von der Klasse implementierte Interfaces, die vorhandenen oder durch Interfaces vorgegebenen Attribute sowie die
implementierten Konstruktoren und Methoden der Klassen der ADT dargestellt. Klassendiagramme zeigten die Verbindungen der Interfaces untereinander sowie die Verbindungen zwischen den prototypischen Implementierungen auf.
Anschließend erfolgte in Abschnitt 6.1.2 der Entwurf der ADT zur Darstellung der steuernden
Kontrollflüsse. Dazu wurde für jede Komponente, die steuernde Metadaten benötigt, ein ADT
in Form eines JAVA-Interfaces entworfen, und durch eine prototypisch implementierte JAVAKlasse umgesetzt. Für jeden ADT erfolgte die Darstellung eines Klassendiagrammes, um die
beteiligten Metadaten-Klassen und Interfaces zu visualisieren.
Weiter wurden in Abschnitt 6.1.3 Metadaten-ADT entworfen, um die Analyse-Algorithmen parametrisieren zu können, die von den Komponenten der ReDiCAt-Architektur implementiert
werden. Auch hier erfolgte die Darstellung in Form von Klassendiagrammen und ausführlichen
Erläuterungen zu den Bereichen Beschreibung, Super- und Sub-Interfaces, Implementierungen
und Methoden bei Interfaces bzw. Beschreibung, implementierte Interfaces, Attribute, Konstruktoren und Methoden bei Klassen.
Abschnitt 6.2 befasste sich mit dem objektorientierten Entwurf der Komponenten der
ReDiCAt-Architektur. Die Komponenten wurden in Form von EnterpriseBeans (EB) entworfen
und textuell beschrieben. Die ausführliche Darstellung, die beim Entwurf der Metadaten-ADT
erfolgte, wurde nach Maßgabe des Betreuers dieser Arbeit an dieser Stelle nicht ausgeführt.
Vielmehr wurde auf die vorhandene Dokumentation im Javadoc-Format hingewiesen, die
unter http://www.miaundpeppi.de/ReDiCAt/ einzusehen ist. Anstelle der ausführlichen Darstellung jeder den EBs zugehörigen Klasse und jedes zugehörigen Interfaces wurden
die entworfenen EB textuell in den Gesamtzusammenhang der Architektur gestellt und in Bezug auf ihre Aufgaben beschrieben.
Im Anschluss daran erfolgte in Abschnitt 6.3 der Entwurf der Sequenz der Methoden-Aufrufe,
unterteilt in die Sequenz der Methodenaufrufe beim Analyse-Ablauf
• der Klassifikator-Induktion, die in Abschnitt 6.3.1 dargestellt wurde,
154
155
• des Meta-Lernens, die in Abschnitt 6.3.2 dargestellt wurde,
• der naiven Klassifikator-Anwendung, die in Abschnitt 6.3.3 dargestellt wurde,
• der Klassifikation über die Ableitung von Selection Graphs aus einem Klassifikator und
deren Wandlung zu Datenbank-Abfragen, die in Abschnitt 6.3.4 dargestellt wurde, und
• der Wartung eines Klassifikators, die in Abschnitt 6.3.5 dargestellt wurde.
Die Darstellung der verschiedenen Analyse-Abläufe erfolgte in Form von SequenzDiagrammen und einer textuellen Beschreibung der genauen Methodenaufrufe in chronologischer Reihenfolge. Sowohl bei den Sequenz-Diagrammen als auch in der textuellen Beschreibung wurden die den Methoden übergebenen Parameter nicht aufgeführt. Diese lassen
sich ebenfalls der Javadoc-Dokumentation entnehmen.
155
156
156
7. Implementierung und Test
Dieses Kapitel beschreibt die prototypische Implementierung der ReDiCAt-Architektur sowie
die Durchführung anschließender Testläufe zur Überprüfung der Funktionalität der Implementierung. Zunächst wird in Abschnitt 7.1 ein Überblick über die Spezifikation des Referenzsystemes gegeben, auf dem die Implementierung der Architektur durchgeführt und getestet
wurde. Anschließend erfolgt in Abschnitt 7.2 die Beschreibung der prototypischen Implementierung der Architektur. Dabei wird noch einmal kurz auf die Vorgaben und Umsetzungen der
Implementierung eingegangen. Die Beschreibung der Testszenarien für die implementierte Architektur folgt in Abschnitt 7.3. Hier werden u.a. die Testläufe in ihrem Ablauf beschrieben
und es werden die Datensätze aufgeführt, die als Eingabe der Testläufe dienen. Die dazu verwendeten Parameter werden in ihren Belegungen aufgezeigt und erörtert. Die Ausgaben der
Testläufe werden nachfolgend in Abhängigkeit der verschiedenen Eingabedaten und AnalyseAbläufe auszugsweise dargestellt. Abschnitt 7.4 befasst sich mit den Vorzügen und den Einschränkungen der durchgeführten Implementierung der Architektur in Bezug auf Vollständigkeit der Umsetzung der aus dem Ausführungsmodell abgeleiteten Architektur. Abschließend
wird in Abschnitt 7.5 eine Zusammenfassung dieses Kapitels gegeben.
7.1. Beschreibung des Referenzsystemes der
Implementierung und des Tests
Die Implementierung der entworfenen Interfaces und Klassen sowie die Umsetzung der Komponenten erfolgte nach der EJB2.0-Spezifikation. Diese umfasst die Umsetzung der Komponenten in Form von Enterprise-Beans, also Session-Beans (SB), Entity-Beans (EB) und
Message-Driven-Beans (MDB). Diese wurden anschließend in einen JBoss-Applikationsserver
eingebettet, der einen EJB-Container und die entsprechenden Dienste bereitstellt, die bereits in
Abschnitt 3.5 aufgeführt und ausführlich beschrieben wurden.
Dabei kann der Server unter einem Windows- oder Unix-Betriebssystem betrieben werden, im
Falle der Testumgebung handelte es sich um ein Gentoo Linux mit Kernel 2.6.10. Der JBossApplikationsserver kam in der Version 4.0.1 zum Einsatz, bei der eingesetzten JAVA-SDKVersion handelt es sich um das JDK 1.5.0. Weiter wurde zur Implementierung der Interfaces,
Klassen und Enterprise-Beans die Eclipse-IDE der Version 3.1.0 M4 mit dem Plugin JBoss
Eclipse IDE in der Version 1.4.0 eingesetzt.
Die Hardware-Ausstattung der Entwicklungs- und Testumgebung umfasste ein Notebook mit
einem Intel Pentium4-Prozessor mit 1,7 GHz und 512 MB Arbeitsspeicher. Für die Installation
aller benötigten Software-Komponenten und für den Testbetrieb sind ca. 500MB Festplattenspeicher erforderlich.
7.2. Prototypische Implementierung der Architektur
Alle Metadaten-Objekte, die in Abschnitt 6.1 entworfen wurden, wurden durch Interfaces in
der Programmiersprache JAVA bezüglich verschiedener Vorgaben spezifiziert. Zu diesen Vor-
157
158
K APITEL 7 - I MPLEMENTIERUNG UND T EST
gaben zählt in erster Linie die Konformität gegenüber den Schnittstellen der an den AnalyseAbläufen beteiligten Komponenten der ReDiCAt-Architektur. Dadurch soll gewährleistet sein,
dass zukünftige Implementierungen dieser Metadaten-Objekte zur implementierten ReDiCAtArchitektur kompatibel sind und innerhalb dieser eingesetzt werden können. Zusätzlich zu
den Interfaces werden die Metadaten-Objekte durch JAVA-Klassen mit dem Namenspräfix
Simple prototypisch implementiert. So soll durch die Implementierung dieser Klassen die
generelle Funktionsfähigkeit der Implementierung der Gesamtarchitektur aufgezeigt werden.
Die Klassen zur Repräsentation der Metadaten-Objekte, die Komponenten steuern sollen, beinhalten die dazu notwendigen, in Abschnitt 6.1.2 beschriebenen Parameter. Die Klassen zur Repräsentation der Metadaten-Objekte, die Ressourcen wie Klassifikatoren oder Klassifikationsergebnisse repräsentieren, werden so implementiert, dass sie die Schnittstellenanforderungen
der Komponenten erfüllen, an denen sie verarbeitet werden. Darüber hinaus besitzen sie jedoch
keine Semantik. Eine ausführliche Implementierung solcher Metadaten-Objekte, die ihnen
auch eine spezifische Semantik verleihen würde, wird durch die Vorgaben der JAVA-Interfaces
dahingehend beeinflusst, dass sie auch die Anforderungen der Architektur bezüglich einer
Schnittstellenkompatibilität erfüllt. Nocheinmal verdeutlicht bedeutet dies, dass die MetadatenObjekte zur Repräsentation von Klassifikatoren und Klassifikationsergebnissen in der prototypischen Implementierung als Klasse mit dem Namenspräfix Simple keine realen Klassifikatoren oder Klassifikationsergebnisse beinhalten, eine prinzipielle Einbettbarkeit dieser jedoch
vorgesehen ist und ermöglicht wird. Anhand der prototypischen Implementierungen dieser
Metadaten-Objekte soll nur gezeigt werden, wie ein Klassifikator oder ein Klassifikationsergebnis durch die Komponenten der Architektur bearbeitet wird, da darin der Schwerpunkt
dieser Arbeit liegt.
Die in Abschnitt 6.2 entworfenen Komponenten wurden in Form von Enterprise-Beans implementiert. Dabei wurden alle Aspekte umgesetzt, die im Entwurf beschrieben wurden. Um
den exakten Aufbau der verschiedenen Bean-Typen aufzuzeigen, sei hier auf den Anhang verwiesen. Dieser zeigt beispielhaft den Code zur Umsetzung verschiedener implementierter Beans unterschiedlichen Typs auf. So wird im Anhang A.1 die GU-SB zur Repräsentation der
globalen, architekturweit gültigen Zeit als Beispiel einer SB anhand des geschriebenen JAVACodes vorgestellt. Eine beispielhafte MDB wird ausschnittsweise anhand des JAVA-Codes der
MVSK-MDB in Anhang A.2 aufgezeigt, und als Beispiel für eine EB wird der JAVA-Code
der MetadataRepository-EB in Anhang A.3 vorgestellt. Auch die zugehörigen XMLFragmente für den Deployment Descriptor und die Datei jboss.xml zur Bindung der JNDINamen an die Beans werden dargestellt.
Zur Erinnerung sei hier noch einmal in der Tabelle 7.1 aufgeführt, welcher Bean-Typ die Implementierung welcher Interfaces und Klassen erfordert. Entsprechend der unterschiedlichen
Aufgaben der Komponenten und Metadaten-Objekte wurden diese als unterschiedliche Typen
von Enterprise Beans umgesetzt.
Die Tabelle 7.2 zeigt die Zuordnung der implementierten Komponenten zum jeweilig zugrunde
liegenden Bean-Typ. Während die Komponenten, die Daten verarbeiten, als Session-Beans umgesetzt wurden, wurden die steuernden und verwaltenden Komponenten als Message-DrivenBeans implementiert. Entity-Beans dienten der Speicherung von Ressourcen. Die Funktionalität der Komponenten und Beans wurde entsprechend der in Kapitel 6 aufgeführten Eigenschaften umgesetzt.
Der Aspekt der Verteiltheit der Komponenten wird durch die Wahl der EJB-Architektur
als Grundlage der Implementierung umgesetzt. Durch die Referenzierung einer EnterpriseBean über ihren JNDI-Namen ist es möglich, Instanzen einer Bean zu nutzen, die über verschiedene EJB-Container verteilt vorliegen. So kann die prototypische Implementierung der
ReDiCAt-Architektur auf verschiedene EJB-Container verteilt installiert werden, auch auf
158
7.2 P ROTOTYPISCHE I MPLEMENTIERUNG DER A RCHITEKTUR
159
EB
EB
Persistenz-Management durch
container
bean
Remote-/ Local-Interface
•
•
•
LocalHome-/ Home-Interface
•
•
•
•
•
•
•
•
•
Konkrete Bean-Klasse
Abstrakte Bean-Klasse
•
Deployment-Deskriptor
•
Persistence Deskriptor
•
SB
MDB
Tabelle 7.1.: Gegenüberstellung von Bean-Typen und Bean-Komponenten (nach [DP02])
E NTITY-B EAN
S ESSION -B EAN
M ESSAGE -D RIVEN B EAN
• ContentResourceStorage
• AK
• AMVK
• BSK
• AnalysisControl
• MetadataRepository
• DBAGK
• DSK
• GU
• MVSK
• TaskStorage
• ID
• IIK
• IMVK
• VKControl
• IVK
• KE
• KK
• KR
• ML
• SGAK
• TD
• VK
• WMVK
Tabelle 7.2.: Zuteilung der implementierten Komponenten zu den Bean-Typen
verschiedenen Servern, die per Netzwerk verbunden sind. Durch ein Mapping der JNDIDienste und -Namensräume entfernter Server und Container in den eigenen JNDI-Dienst ist
es dann möglich, auf entfernt vorliegende Beans zuzugreifen. Dieses Mapping könnte beispielsweise derart ausgeführt werden, dass der JNDI-Namensraum eines entfernten Servers in
ein neues Verzeichnis des lokalen Servers mit dem Namen der Domain des entfernten Servers gelinkt wird. So könnte eine Entity-Bean MetadataRepository, die auf dem Server server1.informatik.uni-oldenburg.de installiert ist, über den JNDI-Namen
jnp://localhost:1099/server1.informatik.uni-oldenburg.de/
MetadataRepositoryHomeRemote referenziert werden. Da die Adressen der
Komponenten, die während eines Analyse-Ablaufes der prototypischen Implementierung der
ReDiCAt-Architektur genutzt werden, parametrisiert sind, ist die Verteilung der Komponenten der Architektur umsetzbar. So kann bei Initiierung eines Analyse-Ablaufes durch Setzen
der entsprechenden Adressen der Zugriff auf entfernte Komponenten durchgeführt werden.
Grundlage dessen ist jedoch die Konfiguration des zugrunde liegenden Applikationsservers,
die ein Mapping der JNDI-Namensräume des entfernten Servers in den eigenen JNDI-Context
ermöglichen muss. Die Adressen der Komponenten werden in der prototypischen Implementierung durch die Client-Applikation JavaUserInterface gesetzt und sind in den zur Analyse zugehörigen Metadaten-Objekten des Typs Task enthalten. Weitere Informationen über die
Referenzierung einer Enterprise-Bean anhand ihres JNDI-Namens sind samt beispielhaftem
JAVA-Code in Anhang B.2 einzusehen.
Bei der Implementierung der Komponenten, die eine Datenquelle an die Architektur anbinden
159
160
sollen, wurde aus den bereits genannten Gründen auf eine konkrete Implementierung der Anbindung der Datenquellen verzichtet. Anstelle dessen werden auf Anfragen hin prototypische
Dummy-Datensätze zurückgegeben, die einen Datensatz repräsentieren sollen, jedoch analog
zur Repräsentation von Klassifikatoren und Klassifikationsergebnissen keinerlei Semantik aufweisen.
7.3. Testszenarien und Testläufe
Um zu zeigen, dass die prototypisch implementierte Architektur die Abläufe abbildet, die im
Ausführungsmodell in Kapitel 4 und im Architekturentwurf in Kapitel 5 konzeptioniert wurden, wurden verschiedene Testläufe durchgeführt und deren Ergebnisse analysiert. In diesem
Abschnitt wird die Durchführung der Testläufe beschrieben, die die identifizierten AnalyseAbläufe der einfachen und inkrementellen Klassifikator-Induktion, des Meta-Lern-Vorganges,
der naiven Klassifikation und der Klassifikation über Selection Graphs sowie der KlassifikatorWartung anhand der prototypisch implementierten ReDiCAt-Architektur umsetzen.
Um einen Testlauf der Architektur zu initiieren, kann die zu Testzwecken implementierte
main()-Methode der Klasse JavaUserInterface mit einem String-Parameter aufgerufen werden, der für die Spezifizierung des auszuführenden Analyse-Ablaufes verantwortlich
ist. Der Aufruf dieser Methode ist in Listing 7.1 dargestellt.
1
java JavaUserInterface ci
Listing 7.1: Aufruf der main()-Methode der Klasse JavaUserInterface
Zulässige Belegungen des Parameters sind:
• ci für die einfache Klassifikator-Induktion,
• ici für die inkrementelle Klassifikator-Induktion,
• ml für einen Meta-Lern-Vorgang,
• naive für eine naive Klassifikator-Anwendung,
• sg für eine Klassifikation unter Verwendung von Selection Graphs und
• maintenance für eine Klassifikator-Wartung.
7.3.1. Test der Abläufe der einfachen und inkrementellen
Nach Übergabe des Wertes ci oder ici als Parameter an die main-Methode des
JavaUserInterface wird eine einfache oder eine inkrementelle Klassifikator-Induktion
anhand der ReDiCAt-Architektur durchgeführt. Dazu bedarf es eines mit spezifischen Werten belegten Objektes vom Typ SimpleInductionTask. Die Erzeugung eines solchen
Objektes erfolgte zu Testzwecken über die Methode initSimpleInductionTask(),
die anhand der übergebenen Parameter entsprechende Metadaten-Objekte erzeugt, die dann
in einem SimpleInductionTask-Objekt zusammengefasst und zum Ablauf der Analyse benötigt werden. Der Aufruf dieser Methode mit den Belegungen der Parameter für eine
einfache Klassifikator-Induktion ist in Listing 7.2 einzusehen.
160
7.3 T ESTSZENARIEN UND T ESTL ÄUFE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
161
SimpleInductionTask task = initSimpleInductionTask(
"ci",
BSKAddresses,
"jnp://localhost:1099/DSKHomeRemote",
"jnp://localhost:1099/IIKHomeRemote",
"queue/redicat-controlQueue",
"jnp://localhost:1099/TDHomeRemote",
"myUser",
"myPass",
classifierSourceAddresses,
classifierSourceUserNames,
classifierSourceUserPasswords,
"jnp://localhost:1099/KRHomeRemote",
"myUser",
"MyPassword",
"both",
System.getProperties());
Listing 7.2: Erzeugung eines SimpleInductionTask-Objektes
Der erste Parameter ist ein String-Objekt, das den Namen des auszuführenden AnalyseAblaufes beinhaltet. Im Falle der einfachen Klassifikator-Induktion hat es den Wert ci, im
Falle der inkrementellen Induktion weist es den Wert ici auf.
Der zweite übergebene Parameter trägt den Namen BSKAddresses. Es handelt sich hierbei
um ein Vector-Objekt, welches String-Objekte enthält, die die JNDI-Namen der Komponenten als Wert aufweisen, die die Selektion der für einen inkrementellen Induktionsvorgang benötigten Klassifikatoren ausführen. Über diese JNDI-Namen werden die Komponenten im weiteren Verlauf der Ausführung des Analyse-Ablaufes durch die Architektur referenziert. Im Falle der einfachen Induktion ist dieses Vector-Objekt leer, da keine Klassifikatoren
für die Induktion benötigt werden und somit auch keine BSK-Komponenten referenziert werden müssen. Im Falle einer inkrementellen Induktion beinhaltet es für jede BSK-Komponente,
die einen Klassifikator selektieren soll, ein String-Objekt mit der Belegung deren JNDINamens.
Der dritte Parameter ist ein String-Objekt, das den JNDI-Namen der Komponente beinhaltet, die für die Selektion der Trainingsdaten verwendet werden soll.
Auch hier wird anhand dieses JNDI-Namens, der in diesem Fall mit der Belegung
jnp://localhost:1099/DSKHomeRemote versehen ist, die Komponente zur Trainingsdatenselektion referenziert. Diese Belegung bewirkt in diesem Analyse-Ablauf, dass
die lokale DSK-Komponente für die Beschaffung der Trainingsdaten herangezogen wird.
Auf diese Weise lassen sich auch alle anderen DSK-Instanzen nutzen, die über den lokalen
JNDI-Namensraum adressierbar sind.
Der vierte Parameter ist ein String-Objekt, welches den JNDI-Namen der Komponente beinhaltet, die den Induktions-Algorithmus implementiert. In diesem Falle bewirkt die Belegung
die Nutzung der lokalen IIK-Komponente.
Der fünfte Parameter ist ein String-Objekt, dessen Belegung für den JNDI-Namen der Nachrichtenschlange steht, die für den Empfang von Bestätigungsnachrichten verantworlich ist. Hier
wird auf die lokale Steuerungsschlange verwiesen.
Der sechste Parameter ist ein String-Objekt, das den JNDI-Namen der Komponente als Belegung aufweist, welche die Datenquelle kapselt, die die Trainingsdaten beinhaltet. Zusammen
mit dem siebten und achten Parameter, die je ein String-Objekt für den Benutzernamen und
das korrespondierende Passwort enthalten, kann auf die Datenquelle zugegriffen werden. Die
161
162
Belegungen der String-Objekte für Benutzernamen und Passwort werden in der prototypischen Implementierung nicht interpretiert und haben lediglich konzeptionellen Charakter, da
die Anbindung der Datenquellen, wie bereits eingangs erwähnt, nicht implementiert wurde,
sondern Dummy-Datensätze zurückgegeben werden. Die Interfaces für die Metadaten-Objekte
zum Zugriff auf Datenquellen fordern hingegen die Implementierung dieser Attribute, um im
Rahmen einer konkreten, ausführlichen Implementierung die Möglichkeit der Authentifizierung gegenüber einer Datenquelle zu ermöglichen.
Analog zu den drei zuvor beschriebenen Parametern dienen der neunte, zehnte und elfte Parameter der Repräsentation von JNDI-Namen, Benutzernamen und Passwörtern zum Zugriff
auf die Datenquellen, in denen die Klassifikatoren gespeichert sind. Es handelt sich bei diesen
Parametern um Vector-Objekte, die mit String-Objekten belegt sind.
Der zwölfte, dreizehnte und vierzehnte Parameter dienen dem Zugriff auf das KlassifikatorRepository, in dem der neu durch die Induktion erzeugte Klassifikator gespeichert werden soll.
Auch zum Zugriff auf diese Datensenke sind JNDI-Name der Komponente, die die Senke beherbergt, sowie Benutzername und Passwort vorgesehen. Die Werte werden jeweils in Form
eines String-Objektes übergeben. Analog zu den Komponenten, die den Zugriff auf eine
Datenquelle lediglich prototypisch umsetzen oder simulieren, werden auch die Komponenten
zur Umsetzung einer Datensenke prototypisch implementiert. Die neu erzeugten Klassifikatoren werden dort also nicht real gespeichert.
Der fünfzehnte Parameter ist ein String-Objekt, welches als Belegung einen Wert trägt, der
die Verwertung der erzeugten Ressource festlegt. In diesem Fall weist es die Belegung both
auf, welche für eine Speicherung und eine Visualisierung der erzeugten Ressource steht.
Der letzte Parameter ist ein Objekt vom Typ Properties, welches eine Menge von Parametern in Form von Schlüssel-Wert-Paaren beinhaltet, die zur Parametrisierung der AnalyseAlgorithmen genutzt werden können. Auch hierin ist lediglich ein konzeptioneller Sinn zu sehen, da die Belegung dieses Objektes in der prototypischen Implementierung nicht interpretiert
wird. Daher wird hier ein beliebiges, irrelevantes Properties-Objekt übergeben.
Auf der Basis dieser sechzehn Parameter wird ein SimpleInductionTask-Objekt erzeugt,
welches der ReDiCAt-Implementierung übergeben wird. Diese extrahiert analog zu dem in
Kapitel 6 beschriebenen Entwurf die einzelnen Metadaten und führt die Analyse durch. Das
Ergebnis der Analyse besteht aus verschiedenen Aspekten. So wird zunächst ein induzierter
Klassifikator ausgegeben.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RESULT: VKBean.visualizeResource(): Prototypical visualisation:
RESULT: VKBean.visualizeResource(): =================================
RESULT: VKBean.visualizeResource(): classifier.
RESULT: VKBean.visualizeResource(): Content:
RESULT: VKBean.visualizeResource(): Description: Prototypische
Implementierung eines Datensatzes, der einen Klassifikator
beschreibt.
RESULT: VKBean.visualizeResource(): vtb: 1106131000000
RESULT: VKBean.visualizeResource(): vte: 1106131951194
RESULT: VKBean.visualizeResource(): ttb: 1108758776475
RESULT: VKBean.visualizeResource(): tte: not set.
RESULT: VKBean.visualizeResource():
Location: jnp://localhost:1099/IIKHomeRemote
RESULT: VKBean.visualizeResource(): UserName: myUser
RESULT: VKBean.visualizeResource(): UserPassword: myPass
Listing 7.3: Ausgabe der Implementierung der Architektur zur Visualisierung eines neu induzierten Klassifikators im Falle einer einfachen Klassifikator-Induktion
162
163
Listing 7.4 zeigt die Ausgaben des Testlaufes, die die prototypische Speicherung des erzeugten
Klassifikators belegen. Auch an dieser Stelle sei noch einmal darauf hingewiesen, dass in der
prototypischen Implementierung der Architektur keine reale Speicherung erfolgt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RESULT: VKBean.storeResource(): Prototypical storage:
RESULT: VKBean.storeResource(): ================================
RESULT: VKBean.storeResource(): classifier
RESULT: VKBean.storeResource(): storage metadata:
RESULT: VKBean.storeResource(): ClassifierSink location
(KR component): jnp://localhost:1099/KRHomeRemote
RESULT: VKBean.storeResource(): ClassifierSink UserName
(KR component): myUser
RESULT: VKBean.storeResource(): ClassifierSink UserPassword
(KR component): MyPassword
DEBUG: KRBean.setClassifier(): ##################
DEBUG: KRBean.setClassifier(): classifier stored: Prototypische
beschreibt.
Listing 7.4: Ausgabe der Implementierung der Architektur zur Speicherung eines neu induzierten Klassifikators im Falle einer einfachen Klassifikator-Induktion
Schließlich wird auch ein Metadaten-Objekt erzeugt und gespeichert, welches den induzierten
Klassifikator beschreibt und nach Durchführung der Induktion als Entity-Bean-Instanz persistent im EJB-Container vorliegt. Die Ausgaben zur Speicherung dieser Entity-Bean sind in
Listing 7.5 dargestellt. In diesem Falle erfolgt eine reale Speicherung, die durch den EJBContainer umgesetzt wird, da die Daten in einer Entity-Bean-Instanz gehalten werden. Diese
werden automatisch vom EJB-Container persistent gespeichert.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
DEBUG: MVSKBean.onMessage(): sending AKMetadata to AK component.
DEBUG: AKBean.storeContentResourceMetadata() entered.
DEBUG: AKBean.storeContentResourceMetadata(): storing metadata set
with values:
DEBUG: AKBean.storeContentResourceMetadata(): type: classifier
DEBUG: AKBean.storeContentResourceMetadata(): dataSourceLocation:
jnp://localhost:1099/TDHomeRemote
DEBUG: AKBean.storeContentResourceMetadata(): description:
Prototypische Implementierung eines Datensatzes, der einen
Klassifikator beschreibt.
DEBUG: AKBean.storeContentResourceMetadata(): contentResourceLocation:
jnp://localhost:1099/KRHomeRemote
DEBUG: AKBean.storeContentResource(): metadata set stored in eb with
id 1108758777160.
Listing 7.5: Ausgabe der Implementierung der Architektur zur Speicherung des MetadatenObjektes über den neu induzierten Klassifikator im Falle einer einfachen
Die vollständigen Ausgaben des Testlaufes zur einfachen Induktion eines Klassifikators sind
im Anhang C.1 einzusehen. In Listing 7.3 ist der Abschnitt der Ausgaben aufgeführt, der die
Visualisierung des neu erzeugten Klassifikators umfasst.
Da Entity-Beans vom EJB-Container auf eine relationale Datenbank gemappt und Instanzen
dieser auch darin gespeichert werden, lässt sich nach dem Testlauf in der relationalen Datenbank Hypersonic des JBoss-Applikationsservers ein Eintrag für die Entity-Bean-Instanz mit
163
164
den Metadaten über den neu erzeugten Klassifikator finden. Dieser Eintrag ist in Abbildung 7.1
einzusehen. Anhand dieser drei Aspekte und der in Anhang C.1 aufgezeigten, weiteren Ausga-
Abbildung 7.1.: Gespeicherte Metadaten über den durch den Testlauf neu erzeugten Klassifikator
ben kann das zu erwartende Verhalten der ReDiCAt-Implementierung nachvollzogen werden.
Der von der ReDiCAt-Implementierung durchgeführte Analyse-Ablauf entspricht dem auf Basis des Ausführungsmodelles und des Architekturentwurfes zu erwartenden Ablauf. So konnte
gezeigt werden, dass die Implementierung den Analyse-Ablauf der einfachen KlassifikatorInduktion abbildet. Hierbei sei noch einmal auf die Einschränkungen hingewiesen, dass der
Fokus der prototypischen Implementierung auf der Schaffung der Kontroll- und Datenflüsse
zwischen den Komponenten liegt, und nicht auf der semantisch korrekten Durchführung der
Analyse unter Erzeugung semantisch korrekter und wertvoller Ressourcen, z.B. eines Klassifikators. Der entstandene Klassifikator trägt keinerlei Semantik. Es handelt sich vielmehr um
ein Objekt, welches durch eine Implementierung mit einem semantisch aussagekräftigen Inhalt
ersetzt werden kann. Der Schwerpunkt liegt in der Umsetzung des Analyse-Ablaufes durch die
Implementierung der Architektur. Fortführende Arbeiten können hier ansetzen und beispielsweise ein Objekt zur Repräsentation eines realen Klassifikators und eines realen Induktionsalgorithmus implementieren, das dann in die Implementierung dieser Arbeit eingebettet werden
kann.
Der Ablauf der inkrementellen Klassifikator-Induktion unterscheidet sich in der prototypischen Implementierung nur in der Phase der Basisklassifikator-Selektion. Im Falle einer inkrementellen Induktion werden hier mehrere Klassifikatoren selektiert und in der
ContentResourceStorage-Entity-Bean-Instanz mit der ID 1 zwischengespeichert. Die
vollständigen Ausgaben eines inkrementellen Analyse-Ablaufes sind in Anhang C.2 aufgeführt. Da auch im Falle einer inkrementellen Klassifikator-Induktion ein Klassifikator entsteht, der sich syntaktisch nicht von einem Klassifikator unterscheidet, der durch eine einfache
Induktion entsteht, wird an dieser Stelle auf die Darstellung der Metadaten über den erzeugten
Klassifikator in der Hypersonic-Datenbank verzichtet.
7.3.2. Test des Ablaufes eines Meta-Lern-Vorganges
Die Tests der weiteren Analyse-Abläufe verlaufen analog zum Test des Ablaufes der
Klassifikator-Induktion. Für den Test des Ablaufes eines Meta-Lern-Vorganges wird wie im
Falle der Klassifikator-Induktion ein Objekt vom Typ SimpleInductionMetadata instantiiert, welches dann von der ReDiCAt-Implementierung verarbeitet wird. Die Ausgaben
eines Meta-Lern-Ablaufes sind in Anhang C.3 einzusehen. Anhand der Ausgaben kann nachvollzogen werden, dass die Architektur den Ablauf des Meta-Lern-Vorganges abbildet. Als
Ergebnis entsteht ein globales Modell, welches in Abbildung 7.2 dargestellt ist.
164
165
Abbildung 7.2.: Gespeicherte Metadaten über das durch den Testlauf neu erzeugte globale Modell
7.3.3. Test der Abläufe der Klassifikator-Anwendungen
Um einen Testlauf einer Klassifikation zu initiieren, kann die main-Methode mit dem Parameter naive oder sg aufgerufen werden. Um eine Klassifikation durchzuführen, muss der Architektur ein Objekt vom Typ SimpleClassificationTask übergeben werden, welches
die steuernden Metadaten beinhaltet. Da das Erzeugen eines solchen Task-Objektes analog
zum zuvor beschriebenen Erzeugen eines SimpleInductionTask-Objektes erfolgt, wird
die Darstellung der Testläufe an dieser Stelle auf den Verweis auf die Ausgaben der Architektur
im Anhang und die Abbildung des gespeicherten Klassifikationsergebnisses in der HypersonicDatenbank des JBoss-Applikationsservers eingeschränkt.
Bei der einfachen Klassifikation ist der in Listing 7.6 abgebildete Ausschnitt der Ausgaben von
Interesse. Anhand der Ausgaben ist zu erkennen, dass eine Ressource der Art classification
Result erzeugt wurde, die prototypisch visualisiert und gespeichert wird.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
RESULT: VKBean.visualizeResource(): classification Result.
Implementierung eines Datensatzes, der ein
Klassifikationsergebnis beschreibt.
RESULT: VKBean.visualizeResource(): Location of result dataset:
jnp://localhost:1099/KEHomeRemote
RESULT: VKBean.visualizeResource(): UserName of result dataset:
myUser
RESULT: VKBean.visualizeResource(): UserPassword of result dataset:
MyPassword
RESULT: VKBean.visualizeResource(): Location of classifier applied:
RESULT: VKBean.visualizeResource(): UserName to access the
classifier applied: myUser
RESULT: VKBean.visualizeResource(): UserPassword to access the
classifier applied: myPass
RESULT: VKBean.storeResource(): =================================
RESULT: VKBean.storeResource(): classification Result.
RESULT: VKBean.storeResource(): ResultDataSetSink location
(KE component): jnp://localhost:1099/KEHomeRemote
165
166
31
32
33
34
35
36
37
38
39
40
RESULT: VKBean.storeResource(): ResultDataSetSink UserName
(KE component): myUser
RESULT: VKBean.storeResource(): ResultDataSetSink UserPassword
(KE component): MyPassword
DEBUG: KEBean.getResultDataSet(): #####################
DEBUG: KEBean.getResultDataSet(): result dataset stored:
Prototypische Implementierung eines Datensatzes, der ein
Listing 7.6: Ausschnitt der Ausgabe des Testlaufes einer naiven Klassifikator-Anwendung
Das zugehörige Metadaten-Objekt wurde ebenfalls erzeugt und kann in der HypersonicDatenbank des JBoss-Applikationsservers eingesehen werden, da es in Form einer EntityBean-Instanz gespeichert wurde. Die Ausgaben zu diesem Vorgang sind in Listing 7.7 einzusehen, eine Abbildung des Datenbankeintrages ist in Abbildung 7.3 dargestellt.
1
2
3
4
5
6
7
8
9
10
11
12
13
DEBUG: AKBean.storeContentResourceMetadata(): storing metadata
set with values:
DEBUG: AKBean.storeContentResourceMetadata(): type:
classificationResult
jnp://localhost:1099/IDHomeRemote
DEBUG: AKBean.storeContentResourceMetadata():
contentResourceLocation: jnp://localhost:1099/KEHomeRemote
DEBUG: AKBean.storeContentResource(): metadata set stored in eb
with id 1108772119124
Listing 7.7: Ausschnitt der Ausgabe des Testlaufes zur Speicherung der Metadaten über das
erzeugte Klassifikationsergebnis
Abbildung 7.3.: Gespeicherte Metadaten über das durch den Testlauf zur naiven KlassifikatorAnwendung neu erzeugte Klassifikationsergebnis
Für weitere Details zum Testlauf der naiven Klassifikator-Anwendung sei hier auf die
vollständige Darstellung aller Ausgaben des Testlaufes zur naiven Klassifikator-Anwendung
der prototypisch implementierten Architektur in Anhang C.4 verwiesen.
Die Klassifikation durch Ableitung von Selection Graphs aus einem Klassifikator und deren
Wandlung zu Datenbank-Abfragen zeigt andere beteiligte Komponenten und Methodenaufrufe. Ein interessanter Ausschnitt der Ausgaben des Testlaufes dieser Analyse ist in Listing 7.8
dargestellt.
166
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
167
DEBUG: AMVKBean.executeClassifierCollection() entered.
DEBUG: AMVKBean.executeClassifierCollection(): bsk address:
jnp://localhost:1099/BSKHomeRemote.
DEBUG: BSKBean.deliverClassifierSet() entered.
DEBUG: BSKBean.deliverClassifier(): kr address:
jnp://localhost:1099/KRHomeRemote.
DEBUG: KRBean.getClassifier() entered.
DEBUG: BSKBean.deliverClassifier(): classifier added to Vector
classifierSet at position 0.
DEBUG: BSKBean.deliverClassifierSet: classifierSet delivered.
DEBUG: AnalysisControlBean.onMessage() entered.
DEBUG: AnalysisControlBean: classifier received.
DEBUG: AnalysisControlBean.onMessage(): classifier set to EB
with id 1
DEBUG: AMVKBean.executeClassifierCollection(): sent command
to execute analysis.
DEBUG: AnalysisControlBean.onMessage(): sent receipt of
classifier set to be stored.
DEBUG: MVSKBean.onMessage(): classifier delivery receipt
received.
DEBUG: AMVKBean.executeAnalysisTask() entered.
DEBUG: AMVKBean.executeAnalysisTask(): sgak address:
jnp://localhost:1099/SGAKHomeRemote
DEBUG: SGAKBean.executeSelectionGraphDerivation() entered.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): EB with pk 1
already exists. Using this one.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): using as
receipt component address.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): using
jnp://localhost:1099/IDHomeRemote as data source component.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): executed
selection graph derivation based on Classifier retreived from
the entity bean ContentResourceStorage. Task was sg
classification.
DEBUG: DBAGKBean.executeQueryProcessing() entered.
DEBUG: DBAGKBean.executeQueryProcessing(): Generated
classification result dataset.
Listing 7.8: Ausschnitt der Ausgabe des Testlaufes der Selection Graph-Klassifikation
Die weitere Verarbeitung des erzeugten Klassifikationsergebnisses erfolgt analog zum zuvor
dargestellten Vorgehen bei der naiven Klassifikation. Die vollständigen Ausgaben des Testlaufes einer Klassifikator-Anwendung durch Ableitung von Selection Graphs aus diesem und
deren Wandlung zu Datenbankabfragen sind in Anhang C.5 dargestellt. Anhand der Ausgaben
der beiden Testläufe der unterschiedlichen Klassifikator-Anwendungen und der erzeugten Ergebnisse kann nachvollzogen werden, dass auch beide Abläufe der Klassifikator-Anwendung,
die durch das Ausführungsmodell und den Architekturentwurf konzeptioniert wurden, von der
Implementierung der Architektur umgesetzt werden.
7.3.4. Test des Ablaufes der Klassifikator-Wartung
Der letzte Testlauf zeigt die Abbildung der Klassifikator-Wartung durch die implementierte
Architektur. Um eine Klassifikator-Wartung durchzuführen, muss ein Metadaten-Objekt vom
167
168
Typ SimpleMaintenanceTask instantiiert und mit passenden Werten belegt werden. Dies
geschieht analog zur Erzeugung des SimpleInductionTask-Objektes über den Aufruf
einer Methode des JavaUserInterface. Die Wartung verläuft in weiten Teilen analog
zur Klassifikator-Induktion. Bevor jedoch ein neuer Klassifikator induziert wird, erfolgt die
Invalidierung des zu wartenden Klassifikators. Die Ausgaben des Testlaufes, die die Invalidierung belegen, sind in Listing 7.9 abgebildet. Die Darstellung der vollständigen Ausgaben der
Klassifikator-Wartung erfolgt in Anhang C.6.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
DEBUG: WVSKBean.onMessage(): using IVK address
jnp://localhost:1099/IVKHomeRemote.
DEBUG: IVKBean.invalidateClassifier(): kr address:
DEBUG: IVKBean.invalidateClassifier(): using global clock to
generate invalidation timestamp.
DEBUG: GUBean.getGlobalTime: global timestamp is:
2005-02-19 01:19:11.016.
DEBUG: KRBean.setClassifier(): classifier stored:
Classifier invalidated by IVK component.
DEBUG: IVKBean.invalidateClassifier(): stored invalidated
classifier at component kr with address:
jnp://localhost:1099/KRHomeRemote and value of
tte: 2005-02-19 01:19:11.016.
Listing 7.9: Ausschnitt der Ausgabe des Testlaufes der Klassifikator-Wartung: Invalidierung
des zu wartenden Klassifikators
7.3.5. Zusammenfassung der Testläufe
Insgesamt wurde versucht, alle Analyse-Abläufe, die vom Ausführungsmodell und der daraus
abgeleiteten Architektur ausführbar sind, durch Testläufe der prototypischen Implementierung
der Architektur nachzuvollziehen. Anhand der Ausgaben der Implementierung und anhand von
entstandenen Einträgen in der Hypersonic-Datenbank des JBoss-Applikationsservers konnte
das erwartete Verhalten beobachtet werden. Somit wurden die Abläufe von der Implementierung korrekt umgesetzt.
7.4. Vorzüge und Einschränkungen der prototypischen
Implementierung
Es wurde bereits zuvor an einigen Stellen erwähnt, dass die Implementierung der ReDiCAtArchitektur prototypisch erfolgte. Der Fokus dieser Arbeit liegt auf der Konzeptionierung der
Analyse-Abläufe in Form eines Ausführungsmodelles und einer daraus abgeleiteten Architektur. Die Implementierung dient dabei als Hilfsmittel, um die konzeptionierten Analyse-Abläufe
demonstrieren zu können. Aus diesen Gründen wurden beispielsweise keine semantisch belegten Datentypen für Klassifikatoren oder Klassifikationsergebnisse implementiert. Der Schwerpunkt der Implementierung der Architektur lag vielmehr auf der Schaffung der verteilten Komponenten und der Umsetzung der Kontroll- und Datenflüsse zwischen ihnen.
Durch die Implementierung von Interfaces, die ein bestimmtes Maß an Vorgaben für nachfolgende, ausführliche Implementierungen der einzelnen Datentypen oder Komponenten geben,
168
169
kann erreicht werden, dass durch Erweiterungen auch Semantik in die Implementierung eingearbeitet werden kann. Richtet sich beispielsweise eine zukünftige Implementierung eines Datentyps zur Darstellung eines Klassifikators nach den Vorgaben des Interfaces Classifier,
so kann sie innerhalb der Architektur eingesetzt werden und diese somit um ein Maß an Semantik bereichern.
Die im Rahmen dieser Arbeit umgesetzte prototypische Implementierung der ReDiCAtArchitektur stellt also einen ersten Schritt dar, auf dem weitere Arbeiten aufbauen können. Sie
ist zum derzeitigen Zeitpunkt in ihrer semantischen Aussagekraft stark eingeschränkt, bietet
jedoch die fast vollständige Umsetzung aller Abläufe des Ausführungsmodelles durch die Implementierung der Kontroll- und Datenflüsse zwischen den Komponenten. Einschränkungen
bestehen in der fehlenden Implementierung der Benutzungsschnittstelle und der daran angeschlossenen Task-Analyse, die durch die Komponenten BS bzw. TA der aus dem Ausführungsmodell abgeleiteten Architektur umgesetzt werden. Von der Implementierung dieser Komponenten wurde nach Maßgabe des Betreuers abgesehen. Weiterhin bestehen Einschränkungen in
der prototypischen Implementierung der Komponenten, die die Analyse-Algorithmen umsetzen. Diese erfüllen derzeit ausschließlich die Spezifikationen der Schnittstellen, weisen jedoch
keine Semantik in Bezug auf die umzusetzende Algorithmik auf. So erzeugt die Komponente
IIK zur Umsetzung eines inkrementellen Induktions-Algorithmus zwar einen syntaktisch korrekten Klassifikator, induziert diesen jedoch nicht anhand eingegebener Datensätze, sondern
statisch.
Auf dem derzeitigen Stand aufbauend kann die Implementierung durch Schaffung semantisch
aussagekräftiger Datentypen für Klassifikatoren und Klassifikationsergebnisse erweitert werden. Auch die Implementierung von Komponenten, die reale Algorithmen umsetzen und eine konkrete Funktionalität bieten, kann die derzeitige Architektur erweitern. Auf diese Weise
kann die semantische Aussagekraft der Implementierung erhöht werden, so dass die AnalyseAbläufe des Ausführungsmodelles, und somit auch die Analysen des ReKlaMe-Ansatzes durch
die ReDiCAt-Implementierung semantisch korrekt umgesetzt werden können.
In diesem Kapitel wurde die Implementierung der ReDiCAt-Architektur vorgestellt und
ausführlich betrachtet. Dazu wurden zunächst in Abschnitt 7.1 die der Implementierung zugrunde liegenden Soft- und Hardwareanforderungen aufgezeigt.
In Abschnitt 7.2 wurden implementationsspezifische Details der implementierten Datentypen
und Komponenten beschrieben. So wurde u.a. eine Abbildung von Komponenten der aus dem
Ausführungsmodell abgeleiteten Architektur auf Enterprise-Bean-Typen durchgeführt.
Abschnitt 7.3 befasste sich anschließend mit dem Vorhaben, die Umsetzung der AnalyseAbläufe, die durch die aus dem Ausführungsmodell abgeleitete Architektur vorgegebenen wurden, anhand der Implementierung nachzuvollziehen. Dazu wurde eine Reihe von Testläufen initiiert, anhand derer die zu erwartenden Analyse-Abläufe nachvollzogen wurden. In Abschnitt
7.3.1 wurde dazu die Durchführung eines solchen Testlaufes detailliert beschrieben. Die eingehenden Belegungen der Parameter wurden aufgezeigt und in ihrer Wirkung erörtert. Anhand
der Ausgaben der ReDiCAt-Implementierung und weiterer Umstände konnte nachvollzogen
werden, dass die zu erwartenden Abläufe von der Implementierung umgesetzt werden. In den
Abschnitten 7.3.2 bis 7.3.4 erfolgte anschließend die Darstellung der weiteren Testläufe, die
jedoch in großen Teilen analog zu dem in Abschnitt 7.3.1 ausführlich beschriebenen Ablauf
verliefen und daher in kompakterer Form dargestellt wurden. Zusätzlich wurde darauf verwiesen, dass die Ausgaben der Architektur zu jedem der Testläufe der unterschiedlichen Analyse-
169
170
Abläufe im Anhang in den Abschnitten C.1 bis C.6 vollständig einzusehen sind. In Abschnitt
7.3.5 wurden dann gemeinsame Beobachtungen aller Testläufe zusammengefasst und bewertet.
Abschnitt 7.4 erörtert schließlich die Vorzüge und die Einschränkungen der prototypischen
Implementierung. Es wurde darauf hingewiesen, dass die Implementierung der Architektur als
ein erster Schritt in der Umsetzung der aus dem Ausführungsmodell abgeleiteten Architektur
darstellt, die eine Basis für weitere Arbeiten darstellt.
Sämtliche Ressourcen der prototypischen Implementierung sind unter
http://www.miaundpeppi.de/ReDiCAt/code/ReDiCAt/
einzusehen. Die Dokumentation des Quellcodes ist unter
http://www.miaundpeppi.de/ReDiCAt/index.html
als Javadoc hinterlegt.
170
8. Zusammenfassung und Ausblick
Dieses Kapitel fasst die Ergebnisse dieser Arbeit zusammen. Dazu werden zunächst in Abschnitt 8.1 die durchgeführten Arbeiten und deren Ergebnisse aufgeführt und mit den Zielen
abgeglichen, die im Vorfeld der Arbeit formuliert wurden. Anschließend erfolgt in Abschnitt
8.2 ein Ausblick auf die Möglichkeiten der Erweiterung der geschaffenen Architektur. Dazu
werden Ansatzpunkte für nachfolgende Arbeiten aufgezeigt und bereits vorhandene Ansätze
vorgestellt, die in den Kontext dieser Arbeit eingeordnet und in die geschaffene Architektur
integriert werden können.
8.1. Ergebnisse der Arbeit
Einführend wurden in Kapitel 2 zunächst die Grundlagen erarbeitet, die für das Verständnis des
Kontextes dieser Arbeit erforderlich sind. Zu diesen Grundlagen zählen das Distributed Data
Mining (DDM), der übergeordnete Prozess des Knowledge Discovery in Databases (KDD) sowie die spezialisierten Analyse-Verfahren der Klassifikation anhand von Entscheidungsbäumen. Es wurden zwei Herangehensweisen an DDM aufgezeigt: die Task-Parallelisierung und die
Datenparallelisierung. Die Form der Darstellung wurde bewusst auf die Aspekte eingeschränkt,
die zum weiteren Verständnis der Schritte dieser Arbeit erforderlich sind.
Im Anschluss daran erfolgte in Kapitel 3 die Vorstellung verschiedener Architektur-Ansätze
und -Konzepte. Die Vorteile eines Architektur-Ansatzes bei der Planung und Umsetzung eines Systemes bestehen vor allem in der besseren Verständlichkeit des zu entwerfenden Systemes sowie in der Schaffung von Wiederverwendbarkeit der zu entwerfenden Komponenten.
Zusätzlich wird die Verteilung der Entwicklung des Systemes auf ein Team von Entwicklern
ermöglicht, die aufgrund einer Aufteilung der Komponentenentwicklung parallel an einem
System arbeiten können. Die Betrachtung verschiedener, komponentenbasierter ArchitekturAnsätze wie z.B. dem Ansatz der agentenbasierten Architektur, dem Mediator-Wrapper-Ansatz
sowie dem Web-Service-Ansatz erbrachte in Verbindung mit der Betrachtung verschiedener
Architektur-Konzepte wie dem der Client-Server-Architektur, der Container-Architektur und
der Multi-Layer-Architektur einen Überblick über die Eigenschaften, die für die im weiteren Verlauf dieser Arbeit zu implementierende Architektur zur Umsetzung der Analysen des
ReKlaMe-Systemes erwünscht sind. In einer anschließenden Bewertung wurden vorhandene
Implementierungen von Architekturen bezüglich ihrer Eignung für die Verwendung im Rahmen dieser Arbeit untersucht, und die J2EE/EJB-Architektur wurde als die geeignetste Architektur zur Umsetzung des zu entwerfenden Ausführungsmodelles gewählt. Ein wichtiger
Aspekt bei dieser Wahl stellt die umfangreiche Unterstützung der EJB-Architektur von Verteiltheit der Komponenten dar, aber auch die Vorgabe der Programmiersprache JAVA begünstigte
die Wahl der EJB-Architektur. Eine andere, agentenbasierte Architektur, die im Rahmen des
Habilitationsprojektes von Dr. Frank Köster implementiert wurde, erschien bezüglich vieler Eigenschaften ebenfalls geeignet, bietet jedoch zusätzliche Funktionalitäten, die im Rahmen dieser Arbeit nicht von Nutzen wären. Da sie jedoch mit erhöhtem Umsetzungsaufwand verbunden sind, wurde von der Verwendung dieser Architektur im Rahmen dieser Arbeit abgesehen.
Im Anschluss an die Wahl der geeigneten Architektur folgte die Erarbeitung der Grundlagen
des gewählten J2EE-Konzeptes und der EJB-Architektur.
171
172
K APITEL 8 - Z USAMMENFASSUNG UND AUSBLICK
Nach Schaffung dieser Grundlagen befasste sich Kapitel 4 mit dem Einstieg in den konzeptionellen Teil dieser Arbeit, der zunächst die Konzeptionierung eines Ausführungsmodelles
für ReKlaMe-Analysen umfasste. Es wurden verschiedene Analyse-Abläufe (KlassifikatorInduktion, Klassifikator-Anwendung und Klassifikator-Wartung) sowie deren Aufteilung in
verschiedene Analyse-Phasen (einfache und inkrementelle Induktion, Meta-Lernen, naive
Klassifikation und die Klassifikation anhand von Selection Graphs) identifiziert. Daraufhin
wurden Operatoren, beispielsweise zur Datenselektion, zur Durchführung eines KlassifikatorInduktionsschrittes oder zur Selektion eines Klassifikators entworfen und bezüglich ihrer Signaturen spezifiziert. Jeder Analyse-Ablauf, der aus einer Verschaltung verschiedener Operatoren besteht, wurde anhand von graphischen Darstellungen erläutert und formal bezüglich der
Konkatenation der entsprechenden Operator-Signaturen beschrieben. Das Ergebnis dieses Kapitels ist ein Ausführungsmodell, welches die im Rahmen des ReKlaMe-Projektes möglichen
Analysen operationalisiert ausführen kann.
Im Anschluss an die Konzeptionierung des Ausführungsmodelles erfolgte in Kapitel 5 die
Ableitung einer Architektur aus dem zuvor konzeptionierten Ausführungsmodell. Dabei wurden die Operatoren des Ausführungsmodelles auf Komponenten abgebildet, und die operationalisierten Abläufe der verschiedenen Analyse-Schritte wurden durch die Verschaltung der Komponenten in drei vorläufigen Architekturen umgesetzt, je eine für den Ablauf
der Klassifikator-Induktion, den Ablauf der Klassifikator-Anwendung und den Ablauf der
Klassifikator-Wartung. Anschließend erfolgte die Zusammenlegung der vorläufigen Architekturen zu einer Gesamt-Architektur, die alle Analyse-Abläufe abbildet. Durch die Zusammenlegung konnten einige Komponenten mehrfach genutzt werden, so dass eine Reduzierung
der Komponenten der Gesamtarchitektur im Vergleich zur Summe der Komponenten der drei
vorläufigen Architekturen zu beobachten ist.
Die zuvor abgeleitete Architektur zur Durchführung der Analysen im ReKlaMe-Kontext wurde
in Kapitel 6 anschließend im Rahmen eines objektorientierten Entwurfes entwickelt und nach
Maßgabe des Betreuers dieser Arbeit prototypisch implementiert. Grundlage dieses Entwurfes bildeten die zuvor gewählte J2EE/EJB-Basisarchitektur und daraus resultierend die Programmiersprache JAVA. Die Architektur erhielt den Namen ReDiCAt, das Akronym steht für
ReKlame Distributed Classification Architecture. Die Implementierung umfasste die prototypische Umsetzung der Datentypen zur Darstellung von Ressourcen wie z.B. Klassifikatoren,
Klassifikationsergebnissen oder Trainings- und Instanzdatenmengen, Metadaten zur Steuerung
der Komponenten und zur Umsetzung der Datenflüsse innerhalb der Architektur sowie eine
ausgewählte Menge weiterer Komponenten, die jeweils ebenfalls prototypisch implementiert
wurden. Die Auswahl der Komponenten erfolgte nach Maßgabe des Betreuers, es wurden alle
Komponenten des Architekturentwurfes implementiert, abgesehen von den Komponenten BS
und TA.
Um die implementierte Architektur testen zu können, und um nachweisen zu können, dass
sie die Analyse-Abläufe des Ausführungsmodelles und der daraus abgeleiteten Architektur
umsetzt, wurden in Kapitel 7 einige Testläufe durchgeführt und beschrieben. Anhand der auszugsweise dargestellten Ausgaben der Architektur und anhand von entstandenen MetadatenObjekten über die durch den Analyse-Ablauf erzeugten Ressourcen konnte nachvollzogen
werden, dass die Analyse-Abläufe in der Implementierung abgebildet wurden. Vollständige
Ausgaben sind im Anhang C aufgeführt.
Insgesamt wurde das Ziel dieser Arbeit umgesetzt, welches in der Konzeptionierung eines
Ausführungsmodelles für ReKlaMe-Analysen und der darauf basierenden Ableitung einer Architektur samt prototypischer Implementierung bestand. Alle Abläufe, die im Rahmen des ReKlaMe-Projektes durchführbar sind, können durch das Ausführungsmodell und die daraus abgeleitete Architektur abgebildet werden. Als nachteilhaft erweist sich, dass die Implementierung lediglich prototypisch erfolgen konnte und diese somit zwar Vorgaben für eine detaillierte
172
8.2 AUSBLICK
173
Implementierung verschiedener Aspekte der Architektur gibt, jedoch im derzeitigen Stadium
keine auf realen Daten basierenden Analysen durchführen und somit keine realen Ergebnisse erzielen kann. Für nachfolgende Arbeiten ist jedoch ein Rahmenwerk entstanden, welches
viele Ansatzpunkte bietet, um verschiedene Komponenten detailliert zu entwerfen und zu implementieren.
8.2. Ausblick
Im Gegensatz zur detaillierten Konzeptionierung des Ausführungsmodelles und der darauf
basierenden Ableitung einer Architektur erfolgte die Implementierung der Architektur prototypisch, so dass sich hier einige Ansatzpunkte bieten, die durch nachfolgende Arbeiten ausgeführt werden können. So sind sämtliche Komponenten, die Analyse-Algorithmen abbilden,
nur bezüglich ihrer Ein- bzw. Ausgabe-Schnittstellen implementiert worden. Die eigentlichen
Algorithmen fanden keine Implementierung. Hier können auf Basis der Interfaces, die entworfen wurden, um die Anbindung der Komponenten an den Kontroll- und Datenfluss umzusetzen, funktionale Komponenten entworfen werden, die einen Analyse-Ablauf ermöglichen, der
reale Ergebnisse in Abhängigkeit von den Eingaben erzeugen kann. Denkbar ist hier der Entwurf eines Klassifikator-Induktions-Algorithmus, eines Meta-Lerners oder eines KlassifikatorAnwendungs-Algorithmus. Auch der Ablauf der Klassifikation über die Wandlung eines Klassifikators in eine Menge von Selection Graphs und der anschließend folgenden Wandlung dieser zu Datenbank-Abfragen könnte konkret implementiert werden. Zudem ist eine Parameterisierung der implementierten Algorithmen vorgesehen, die ebenfalls prototypisch implementiert
wurde. Diese müsste in Abhängigkeit der zu implementierenden Analyse-Algorithmen ebenfalls detailliert implementiert werden.
Die Modelle für Ressourcen, die im Rahmen der ReKlaMe-Analysen entstehen, sind ebenfalls
prototypisch implementiert worden. Die detaillierte Implementierung eines Modelles zur Abbildung eines Klassifikators oder eines Klassifikationsergebnisses stellt hier einen Ansatzpunkt
dar, um eine reale Funktionalität der Architektur zu erreichen. In der derzeitigen Implementierung handelt es sich um Dummy-Datentypen. Eine reale Repräsentation eines Klassifikators
oder eines Klassifikationsergebnisses wurde nicht umgesetzt.
Auch die Anbindung von Datenquellen und die Darstellung selektierter Datenmengen wurde
nicht detailliert implementiert. Die Konzeptionierung der Architektur sieht verschiedene Komponenten für die Selektion von Daten oder Ressourcen vor. Hier besteht ein Ansatzpunkt für die
detaillierte Implementierung der Komponenten DSK für die Datenselektion von Trainings- oder
Instanzdatenmengen oder BSK für die Selektion von Basisklassifikatoren. Komponenten, die
Datenquellen an die Architektur anbinden, sind KE zur Speicherung von Klassifikationsergebnissen, KR zur Speicherung von Klassifikatoren, TD zur Selektion von Trainingsdatenmengen
und ID zur Selektion von zu klassifizierenden Instanzdatenmengen. Die derzeitigen Implementierungen dieser Komponenten erfüllen die Anforderungen an die Schnittstellen, bieten jedoch
keine reale Speicherung der übergebenen Ressourcen.
Die Initiierung von Analysen erfolgt in der prototypischen Implementierung durch eine statische JAVA-Clientapplikation, in die Parameter und Eingabedaten fest einprogrammiert wurden.
Von der ursprünglich angedachten Implementierung einer webbasierten Benutzungsschnittstelle wurde nach Maßgabe des Betreuers abgesehen, da diese für die Testläufe keinen Mehrwert
erbringt. Hier bietet sich der Ansatzpunkt der detaillierten Implementierung einer Benutzungsschnittstelle, die analog zum konzeptionierten Vorgehen des Ausführungsmodelles auch bereits
vorhandene Ressourcen der Architektur mit in die Planung eines auszuführenden AnalyseAblaufes einbezieht und es komfortabel ermöglicht, Analysen zu planen und zu initiieren.
173
174
K APITEL 8 - Z USAMMENFASSUNG UND AUSBLICK
Auch komplexere Analysen, die aus mehr als einem Analyse-Ablauf bestehen, können hier
umgesetzt werden.
Schließlich wurden die Komponenten der Architektur prototypisch implementiert, die mit der
Verwertung der durch die Analysen erzeugten Ressourcen betraut sind. Auch an dieser Stelle
kann die Entwicklung einer Komponente zur realen Speicherung einer erzeugten Ressource
wie z.B. eines Klassifikators oder eines Klassifikationsergebnisses ansetzen. Die Visualisierung einer solchen Ressource wurde zudem prototypisch implementiert. Hier ließen sich beispielsweise graphische Visualisierungen umsetzen. Die derzeitigen Implementierungen sehen
lediglich eine textuelle Ausgabe der erzeugten Ressourcen vor, die Speicherung erfolgt nicht
real.
Weitere Arbeiten, die im Rahmen des ReKlaMe-Projektes unter der Betreuung von Herrn Heiko
Tapken durchgeführt wurden oder die sich in Planung befinden, können in den Kontext dieser
Arbeit eingeordnet werden. Teile der zuvor erwähnten Erweiterungsmöglichkeiten ließen sich
so möglicherweise bereits umsetzen.
So hat Herr Carsten Saathoff im Rahmen seiner Diplomarbeit ein Metadatenmodell entworfen
und implementiert, welches die Anwendung von Entscheidungsbäumen in Data Warehouses
ermöglicht [Saa04]. Dieses Metadatenmodell könnte zur Darstellung von Klassifikatoren in der
ReDiCAt-Architektur verwendet werden. Zu prüfen ist hier der notwendige Aufwand, um das
Metadatenmodell an die vorgegebenen Auflagen der ReDiCAt-Architektur anzupassen. Hier
stellen die Verwendung des CWM-Standards und die Speicherung der Metadaten in einem
TOY-Repository [HT01] den größten Anpassungsbedarf dar.
Herr Matthias Pretzer entwickelte im Rahmen seiner Diplomarbeit einen Meta-LernAlgorithmus, der datenschutzrechtliche Aspekte berücksichtigt [Pre05]. Bezüglich der Integration in die ReDiCAt-Architektur ist hier eine Anpassung und Integration dieses Algorithmus in die ML-Komponente denkbar, die derzeit lediglich die Schnittstellen-Spezifikation der
Komponente implementiert, auf die Umsetzung eines realen Meta-Lern-Algorithmus jedoch
verzichtet.
Die Diplomarbeit von Herrn Tim Hobbiebrunken beinhaltet die Konzeptionierung eines inkrementellen Klassifikator-Induktions-Algorithmus. Dieser kann die Grundlage einer Implementierung der IIK-Komponente darstellen, die in ihrer derzeitigen Implementierung analog zur
ML-Komponente lediglich die Schnittstellenspezifikationen erfüllt.
Herr Guido Zendel befasste sich im Rahmen seiner Diplomarbeit mit der Implementierung eines Entscheidungsbaum-Induktionsalgorithmus, der direkt auf relationalen Strukturen wie dem
Snowflake-Schema eines Data Warehouse arbeitet [Zen05]. Auch hier bieten sich Ansatzpunkte, diesen Induktionsalgorithmus an die Anforderungen der Komponente IIK der ReDiCAtArchitektur anzupassen und als solches zu implementieren.
Eine zukünftige Arbeit im Rahmen des ReKlaMe-Projektes unter der Betreuung von Herrn
Heiko Tapken befasst sich mit dem Gebiet des Privacy Preserving Data Mining (PPDM). Ergebnisse dieser Arbeit können ebenfalls in potentielle weitere Implementierungen der Komponenten einbezogen werden. In der derzeitigen Implementierung wurde nach Maßgabe des
Betreuers auf die Umsetzung von datenschutzrechtlichen Aspekten verzichtet.
174
Anhang
175
A. Detaillierte Darstellung der
Bestandteile von Enterprise-Beans
Dieser Abschnitt zeigt den Aufbau der Bestandteile auf, aus denen Enterprise-Beans bestehen.
Da jeder der drei Beantypen (Session-Bean, Message-Driven-Bean, Entity-Bean) aus unterschiedlichen Interfaces, Klassen oder sonstigen Ressourcen besteht, wird für jeden Bean-Typ
ein Beispiel aufgeführt. Anhand dieser Beispiele, in denen JAVA- und XML-Codefragmente
dargestellt werden, kann der Aufbau der Enterprise-Beans nachvollzogen werden.
A.1. Interfaces und Klassen zur Definition der GU-SB
Zur Definition der GU-SB bedarf es verschiedener Klassen, Interfaces und XML-Dokumente,
die hier in Form von JAVA- und XML-Code dargestellt werden:
Das GUHomeRemote-Interface muss vom Interface javax.ejb.EJBHome abgeleitet
werden, das wiederum von java.rmi.Remote abgeleitet ist. Auch hier müssen alle Methoden eine Exception vom Typ java.rmi.RemoteException werfen. Sie
dient als eine Art ObjectFactory. Die Implementierung dieser Klasse dient später der
Erzeugung, dem Auffinden und der Löschung von GUBean-Instanzen. Der Code ist in
Listing A.1 gegeben.
1
2
3
4
/*
* Created on Jan 31, 2005
*/
package redicat.mvs;
5
6
7
8
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
9
10
11
12
13
14
15
16
17
/**
* GUHomeRemote.java, created on Jan 31, 2005,
*
* the remote home interface to control the lifecycle of the
* GUBean.
* @author R. Stuber <[email protected]>
*/
public interface GUHomeRemote extends EJBHome {
18
public GURemote create() throws
RemoteException, CreateException;
19
20
21
}
Listing A.1: Code des HomeRemote-Interfaces der GU-Bean
Die Home- und Remote-Interfaces einer Bean können sowohl für lokalen als auch für
entfernten Zugriff konzeptioniert werden. In diesem Falle handelt es sich um den entfernt
konzeptionierten Zugriff, daher der Name HomeRemote.
177
178
K APITEL A - D ETAILLIERTE D ARSTELLUNG DER B ESTANDTEILE VON E NTERPRISE -B EANS
Das Remote-Interface definiert die von einer Bean an Clients angebotenen Geschäftsmethoden und Funktionalitäten. Es muss vom Interface javax.ejb.EJBObject abgeleitet werden, welches selbst vom Interface java.rmi.Remote abgeleitet ist. Zudem
muss die Exception java.rmi.RemoteException deklariert werden. Die Implementierung dieses Interfaces zeichnet später zusätzlich für das transaktionale Verhalten,
die Sicherheitsüberprüfungen sowie gegebenenfalls für die Logik der containergesteuerten Persistenz verantwortlich. Der Code für das Remote-Interface der GU-SB ist in
Listing A.2 gegeben.
1
2
3
4
/*
*/
5
6
7
8
import java.sql.Timestamp;
import javax.ejb.EJBObject;
9
10
11
12
13
14
15
16
17
/**
* GURemote.java, created on Jan 31, 2005,
*
* the remote interface to access business methods of the
* GUBean.
*/
public interface GURemote extends EJBObject {
18
/**
* Method to deliver the global timestamp for all containers
* involved in the ReDiCAt architecture.
* @return Timestamp of the actual time.
* @throws RemoteException
*/
public Timestamp getGlobalTime() throws RemoteException;
19
20
21
22
23
24
25
26
}
Listing A.2: Code des Remote-Interfaces der GU-SB
Die GUBean-Bean-Klasse dient der Implementierung der Methoden, die im Homeund Remote-Interface deklariert wurden. Dabei ist zu beachten, dass die Signaturen der Methoden aus dem Remote-Interface mit den zu implementierenden Methoden übereinstimmen. Je nachdem, welche Art von Enterprise-Bean implementiert werden soll, muss eines der drei Interfaces javax.ejb.EntityBean,
javax.ejb.MessageDrivenBean oder, wie in diesem Beispiel, das Interface
javax.ejb.SessionBean implementiert werden. Dabei müssen die jeweiligen
Home- und Remote-Interfaces nicht implementiert werden. Sie werden später vom EJBContainer bei Installation (Deployment) der Beans von den Installations-Werkzeugen
erzeugt. Mit Ausnahme einer Entity-Bean mit container-managed Persistence werden
die Bean-Klassen als konkrete Klassen implementiert. Der Code der GUBean-BeanKlasse ist in Listing A.3 zu finden.
1
2
3
4
5
/*
*
*/
6
178
A.1 I NTERFACES UND K LASSEN ZUR D EFINITION DER GU-SB
7
8
9
10
11
12
13
14
15
16
import
import
import
import
import
import
import
import
import
import
179
java.rmi.RemoteException;
java.sql.Timestamp;
java.util.Calendar;
javax.ejb.CreateException;
javax.ejb.EJBException;
javax.ejb.SessionBean;
javax.ejb.SessionContext;
javax.naming.Context;
javax.naming.InitialContext;
javax.naming.NamingException;
17
18
19
20
21
/**
* GU-Bean
*/
public class GUBean implements SessionBean {
22
/**
* Default create method
* @throws CreateException
*/
public void ejbCreate() throws CreateException {
}
/**
* Method to return the global timestamp for the redicat
* architecture.
* @return
*/
public Timestamp getGlobalTime() {
Timestamp ts =
new Timestamp(
Calendar.getInstance().getTimeInMillis());
System.out.println(
"DEBUG: GUBean.getGlobalTime: global timestamp is: "
+ts.toString()+".");
return ts;
}
/*
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws
EJBException, RemoteException {
}
/*
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws
}
/*
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws
}
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
}
Listing A.3: Code der Bean-Klasse der GU-SB
179
180
Der Deployment-Deskriptor liegt als XML-Datei vor und beinhaltet zusätzliche, deklarative Informationen, die nicht im Code einer Bean vorhanden sind. Auch Informationen darüber, wie mehrere Enterprise-Beans zusammenzufassen oder einzelne EnterpriseBeans in einem EJB-Container zu installieren sind, sind im Deployment-Deskriptor enthalten. Er beschreibt, welche externen Abhängigkeiten gegenüber anderen EnterpriseBeans oder Ressourcen vorliegen, sowie das Verhalten der Enterprise-Bean zur Laufzeit
und die Möglichkeiten der Kombination mit anderen Enterprise-Beans. Ein Beispiel für
einen Deployment-Deskriptor ist in Listing A.4 aufgezeigt. Es enthält die Ausschnitte,
die zur Deklaration der GU-SB erforderlich sind, und ist nicht vollständig wiedergegeben.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC
"-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
"http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<description><![CDATA[No Description.]]></description>
<enterprise-beans>

<session>
<ejb-name>GU</ejb-name>
<home>redicat.mvs.GUHomeRemote</home>
<remote>redicat.mvs.GURemote</remote>
<ejb-class>redicat.mvs.GUBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<security-identity>
<use-caller-identity></use-caller-identity>
</security-identity>
</session>
<session>
<ejb-name>IVK</ejb-name>
[...]
<ejb-ref>
<ejb-ref-name>GU</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>GUHomeRemote</home>
<remote>GURemote</remote>
</ejb-ref>
<ejb-ref>
[...]
</ejb-ref>
<security-identity>
</session>
[...]
</ejb-jar>
Listing A.4: Code-Beispiel eines Deployment-Deskriptors
Die Datei jboss.xml , ein JBoss-spezifischer XML-Deskriptor, ordnet jeder Bean einen
JNDI-Namen zu, über den diese im Namens- und Verzeichnisdienst eines EJBContainers aufzufinden ist und referenziert werden kann. Der XML-Code der verwendeten jboss.xml ist in Listing A.5 dargestellt.
1
2
3
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
180
A.2 I NTERFACES UND K LASSEN ZUR D EFINITION DER MVSK-MDB
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
181
<jboss>
<enterprise-beans>
<session>
<ejb-name>GU</ejb-name>
<jndi-name>GUHomeRemote</jndi-name>
</session>
<session>
<ejb-name>IVK</ejb-name>
<jndi-name>IVKHomeRemote</jndi-name>
<ejb-ref>
<ejb-ref-name>GU</ejb-ref-name>
<jndi-name>GUHomeRemote</jndi-name>
</ejb-ref>
</session>
</enterprise-beans>
[...]
</jboss>
Listing A.5: Code-Beispiel der Datei jboss.xml
Nach Implementation werden alle Klassen und Deskriptoren in einem jar-Archiv1 verpackt,
welches die Bean-Repräsentation darstellt. Dieses jar-Archiv ist die Grundlage der Installation
einer Bean in einem EJB-Container. Der genaue Ablauf der Installation der Beans im EJBContainer wird in Anhang B beschrieben.
A.2. Interfaces und Klassen zur Definition der MVSK-MDB
Die implementierten MDB bedürfen keiner HomeRemote- und Remote-Interfaces. Hier genügt
es, eine Bean-Klasse zu schreiben, die eine onMessage()-Methode implementiert. Diese
wird aufgerufen, sobald eine Nachricht an die Queue geschickt wird, die durch die MDB observiert wird. Im Falle der MVSK-MDB ist dies die controlQueue.
Die controlQueue wird durch den in Listing A.6 dargestellten XML-Code im JBoss-EJBContainer installiert.
1
2
3
4
5
6
7
8
9
<server>
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=controlQueue">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
</server>
Listing A.6: XML-Code zur Einrichtung der controlQueue in einem JBoss-EJB-Container
Die MVSK-Beanklasse implementiert eine onMessage()-Methode, die aufgerufen wird,
wenn eine Nachricht an die controlQueue gesendet wird. In Abhängigkeit des Typs
1
jar steht für Java Archive und ist technisch gesehen ein zip-komprimiertes Format.
181
182
der Nachricht, die empfangen wurde, kann diese Objekte und String-Properties enthalten. Das Listing zeigt exemplarisch den Zugriff auf eine in einer ObjectMessage enthaltene String-Property Task, deren Wert in dem String-Objekt taskString abgelegt wird. Weiter wird ein Objekt des Typs Task, welches über die ObjectMessageNachricht an die MDB übergeben wurde, aus dieser extrahiert und in einem TaskObjekt gespeichert. Somit wird gezeigt, wie ein Objekt aus einer Nachricht zu extrahieren ist. Der JAVA-Code zur Implementierung der MVSK-SB sei in Listing A.7 gegeben.
1
2
3
4
/*
*/
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
javax.ejb.MessageDrivenBean;
javax.ejb.MessageDrivenContext;
javax.jms.Message;
javax.jms.MessageListener;
javax.jms.ObjectMessage;
javax.naming.Context;
javax.naming.InitialContext;
javax.naming.NamingException;
javax.rmi.PortableRemoteObject;
redicat.aa.ContentResourceStorageHomeRemote;
redicat.aa.ContentResourceStorageRemote;
redicat.aa.IVKHomeRemote;
redicat.aa.IVKRemote;
redicat.metadata.SimpleClassificationTask;
redicat.metadata.SimpleClassifierLocation;
redicat.metadata.SimpleInductionTask;
redicat.metadata.SimpleMaintenanceTask;
redicat.metadata.Task;
redicat.metadata.control.AKMetadata;
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
/**
* MVSKBean.java, created on Jan 16, 2005,
*
* is a message-driven bean to control the task to be executed by the
* ReDiCAt architecture. The queue called redicat-controlQueue will be
* observed for messages containing metadata objects containing
* information to execute an analysis task. The kind of task to be
* executed will be determined by the StringProperty given within
* the message. Possible tasks are:
* <ul>
* <li>naive for naive classifier application,</li>
* <li>sg for selection graph/database query application,</li>
* <li>ci for simple classifier induction,</li>
* <li>ici for incremental classifier induction,</li>
* <li>ml for metalearning,</li>
* <li>maintenance for maintenance.</li>
* </ul>
* After receiving the task and the corresponding metadata, the
* task will be executed. This bean is the central control instance
* of the ReDiCAt architecture.
*/
public class MVSKBean implements MessageDrivenBean, MessageListener {
50
182
A.2 I NTERFACES UND K LASSEN ZUR D EFINITION DER MVSK-MDB
MessageDrivenContext ejbContext;
Context jndiContext;
/*
* @see javax.ejb.MessageDrivenBean#setMessageDrivenContext(
*
javax.ejb.MessageDrivenContext)
*/
public void setMessageDrivenContext(MessageDrivenContext ctx)
throws EJBException {
ejbContext = ctx;
try {
jndiContext = new InitialContext();
} catch (NamingException ne) {
throw new EJBException(ne);
}
}
/**
* Default create method
* @throws CreateException
*/
public void ejbCreate() {
}
/*
* @see javax.jms.MessageListener#onMessage(
*
javax.jms.Message)
*/
public void onMessage(Message message) {
// Place the code to be performed on receiving a message
// here
ObjectMessage controlMessage = (ObjectMessage) message;
String taskString =
controlMessage.getStringProperty("Task");
Task task = controlMessage.getObject();
}
/*
* @see javax.ejb.MessageDrivenBean#ejbRemove()
*/
public void ejbRemove() throws EJBException {
}
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
183
}
Listing A.7: Code der Bean-Klasse der MVSK-MDB
Der Deployment-Deskriptor umfasst im Falle einer MDB die in Listing A.8 abgebildeten
XML-Tags:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<ejb-jar>
<enterprise-beans>
<session>
[...]
</session>

<entity>
[...]
183
184
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
</entity>

<message-driven>
<ejb-name>MVSK</ejb-name>
<ejb-class>redicat.mvs.MVSKBean</ejb-class>
<transaction-type>Container</transaction-type>
<acknowledge-mode>
Auto-acknowledge
</acknowledge-mode>
<message-driven-destination>
<destination-type>
javax.jms.Queue
</destination-type>
</message-driven-destination>
<ejb-ref>
<ejb-ref-name>AMVK</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>AMVKHomeRemote</home>
<remote>AMVKRemote</remote>
</ejb-ref>
[...]
<resource-ref>
<res-ref-name>jms/QueueFactory</res-ref-name>
<res-type>
javax.jms.QueueConnectionFactory
</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</message-driven>
</enterprise-beans>
[...]
</ejb-jar>
Listing A.8: Code-Beispiel eines Deployment-Deskriptors
Die Datei jboss.xml umfasst die Bindung der zu observierenden Message-Queue an die
MDB. Dazu sei das XML-Codefragment aus Listing A.9 einzusehen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<!DOCTYPE jboss PUBLIC
"-//JBoss//DTD JBOSS 3.2//EN"
<jboss>
<enterprise-beans>
<session>
[...]
</session>
<entity>
[...]
</entity>
<message-driven>
<ejb-name>MVSK</ejb-name>
<destination-jndi-name>
queue/redicat-controlQueue
</destination-jndi-name>
<ejb-ref>
<ejb-ref-name>AMVK</ejb-ref-name>
<jndi-name>AMVKHomeRemote</jndi-name>
</ejb-ref>
184
A.3 I NTERFACES UND K LASSEN ZUR D EFINITION DER M E T A D A T A R E P O S I T O R Y -EB
22
23
24
25
26
</message-driven>
[...]
</enterprise-beans>
[...]
</jboss>
Listing A.9: Code-Beispiel der Datei jboss.xml für die MVSK-MDB
A.3. Interfaces und Klassen zur Definition der
MetadataRepository-EB
Eine EB zu implementieren, bedarf eines etwas größeren Aufwandes. Anstelle der Implementierung einer eigenen Primärschlüssel-Klasse wird die JAVA-Klasse java.lang.Long als
Primärschlüssel-Klasse genutzt, so dass hier auf die Darstellung der Primärschlüssel-Klasse
verzichtet wird. Folgende Klassen, Interfaces und XML-Dateifragmente sind zu implementieren:
Das Home-Interface MetadataRepositoryHomeRemote bietet analog zum in Anhang A.1 beschriebenen Home-Interface die Methoden zur Verwaltung des Lebenszyklus der EB. Zusätzlich werden hier jedoch Methoden zum Aufspüren von EBInstanzen deklariert. Diese müssen in Form von EJB-QL-Ausdrücken im DeploymentDeskriptor umgesetzt werden. Diese Umsetzung wird in diesem Abschnitt an späterer
Stelle erläutert. Listing A.10 zeigt das Home-Interface der MetadataRepositoryEB.
Die in diesem Beispiel angegebene EB ist anhand des Wertes eines der Attribute, für
das eine findBy...()-Methode implementiert wurde, auffindbar. Zusätzlich kann sie
anhand ihrer ID vom Typ java.lang.Long aufgefunden werden, die dazu benötigte Methode findByPrimaryKey() wird automatisch vom Container implementiert
und bedarf keiner Deklaration im Home-Interface. Die Implementierung findet bei der
Installation der EB durch den EJB-Container statt.
1
2
3
4
/*
*/
5
6
7
8
9
10
import
import
import
import
import
java.util.Collection;
javax.ejb.EJBHome;
javax.ejb.FinderException;
11
12
13
14
15
16
17
18
19
/**
* MetadataRepositoryHomeRemote.java, created on Jan 27, 2005,
*
* the remote home interface to control the lifecycle of the
* MetadataRepositoryBean.
* @author R. <[email protected]>
*/
public interface MetadataRepositoryHomeRemote extends EJBHome {
20
21
22
public MetadataRepositoryRemote create(Long id)
throws CreateException, RemoteException;
185
185
186
23
public MetadataRepositoryRemote findByPrimaryKey(Long pk)
throws FinderException, RemoteException;
24
25
26
public Collection findByType(String type)
27
28
29
public Collection findByDataSourceLocation(
String dataSourceLocation)
30
31
32
33
public Collection findByDescription(String description)
34
35
36
public Collection findByResourceLocation
(String resourceLocation)
37
38
39
40
}
Listing A.10: Code des HomeRemote-Interfaces der MetadataRepository-EB
Das Remote-Interface MetadataRepositoryRemote umfasst die Deklaration der
Methoden, die von der MetadataRepository-EB angeboten werden. Im Falle dieser EB sind dies die get- und set-Methoden für die vorhandenen Attribute. Einzusehen
ist der JAVA-Code des Remote-Interfaces in Listing A.11.
1
2
3
4
/*
*/
5
6
7
import javax.ejb.EJBObject;
8
9
10
11
12
13
14
15
16
/**
* MetadataRepositoryRemote.java, created on Jan 27, 2005,
*
* the remote interface to access business methods of the
* MetadataRepository bean.
*/
public interface MetadataRepositoryRemote extends EJBObject {
17
public String getType() throws RemoteException;
public void setType(String type) throws RemoteException;
18
19
20
public String getDataSourceLocation() throws RemoteException;
public void setDataSourceLocation(String dataSourceLocation)
throws RemoteException;
21
22
23
24
public String getDescription() throws RemoteException;
public void setDescription(String description)
25
26
27
28
public String getResourceLocation() throws RemoteException;
public void setResourceLocation(String resourceLocation)
29
30
31
32
}
186
Listing A.11: Code des Remote-Interfaces der MetadataRepository-EB
Die Bean-Klasse MetadataRepositoryBean dient der Definition der Attribute, die in der EB gespeichert werden sollen, und implementiert das Interface
javax.ejb.EntityBean. Zur Definition der Attribute werden diese jedoch nicht
wie in herkömmlichen Java-Klassen deklariert. Seit EJB2.0 werden anstelle dessen die
get- und set-Methoden für die Attribute definiert, die der EJB-Container ebenfalls zur
Installation der EB im Container implementiert. Zusätzlich muss die ejbCreate()Methode implementiert werden, die in diesem Fall eine neue EB erzeugt und ihrem
Primärschlüssel-Attribut ID einen Wert zuweist. Der JAVA-Code der Bean-Klasse ist in
Listing ejb:metadatarepositorybean dargestellt.
1
2
3
4
/*
*/
5
6
7
8
9
10
11
import
import
import
import
import
import
javax.ejb.EntityBean;
javax.ejb.EntityContext;
javax.ejb.RemoveException;
12
13
14
public abstract class MetadataRepositoryBean implements
EntityBean {
15
16
17
18
19
public Long ejbCreate(Long id) throws CreateException {
this.setId(id);
return null;
}
20
21
22
public void ejbPostCreate(Long id) {
}
23
24
25
public abstract Long getId();
public abstract void setId(Long id);
26
27
28
public abstract String getType();
public abstract void setType(String type);
29
30
31
32
public abstract String getDataSourceLocation();
public abstract void setDataSourceLocation(
String dataSourceLocation);
33
34
35
36
public abstract String getDescription();
public abstract void setDescription(
String description);
37
38
39
40
public abstract String getResourceLocation();
public abstract void setResourceLocation(
String resourceLocation);
41
42
43
44
/**
* @see javax.ejb.EntityBean#setEntityContext(
*
javax.ejb.EntityContext)
187
187
188
*/
public void setEntityContext(EntityContext ctx)
throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#unsetEntityContext()
*/
public void unsetEntityContext() throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#ejbActivate()
*/
public void ejbActivate() throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#ejbLoad()
*/
public void ejbLoad() throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#ejbStore()
*/
public void ejbStore() throws EJBException,
RemoteException {
}
/**
* @see javax.ejb.EntityBean#ejbRemove()
*/
public void ejbRemove() throws RemoveException,
}
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
}
Listing A.12: Code der Bean-Klasse der MetadataRepository-EB
Der Deployment-Deskriptor ist im Falle einer EB etwas umfangreicher zu deklarieren.
Zunächst werden im Abschnitt der SB-Deklarationen die SB, die einen Zugriff auf die
einzufügende EB durchführen, mit einem <ejb-ref>-Tag erweitert, welches einen
Zugriff auf die EB ermöglicht. Die Deklaration der EB im <entity>-Tag ist im
Falle der MetadataRepository-EB umfangreich, da diese Bean Methoden implementiert, die das Auffinden einer EB-Instanz anhand weiterer Attribute neben dem
Primärschlüssel erlauben.
Zunächst werden die bekannten Deklarationen bezüglich der Namen des Home- und
Remote-Interfaces gegeben. Über das Tag <persistence-type> kann festgelegt
werden, ob Container oder Bean die Persistenzsicherung implementieren sollen. Der
Typ der Primärschlüsselklasse wird im Tag <prim-key-class> festgelegt. Das Tag
188
<reentrant> bestimmt, ob eine EB-Instanz, auf die bereits von einer Methode zugegriffen wird, einen Zugriff einer weiteren Methode erlaubt. Schließlich werden die
Attribute der EB in <cmp-field> deklariert.
Für jedes Attribut, das über eine findBy...()-Methode gesucht werden kann, bedarf
es eines <query>-Tags, welches unter anderem den Attributnamen und ein Suchkriterium in Form eines EJB-QL-Ausdruckes umfasst. EJB-QL erinnert in Bezug auf die
Syntax stark an SQL, die Angabe ?1 bezieht sich auf das erste übergebene Argument
der findBy...()-Methode.
Der XML-Code für die Deklaration der MetadataRepository-EB ist in Listing
A.13 dargestellt. Für weitere Informationen sei hier auf [MH02] verwiesen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
<ejb-jar>
<enterprise-beans>
[...]
<session>
<ejb-name>AK</ejb-name>
[...]
<ejb-ref>
<ejb-ref-name>MetadataRepository</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>MetadataRepositoryHomeRemote</home>
<remote>MetadataRepositoryRemote</remote>
</ejb-ref>
[...]
</session>
[...]

<entity>
<ejb-name>MetadataRepository</ejb-name>
<home>
redicat.mvs.MetadataRepositoryHomeRemote
</home>
<remote>
redicat.mvs.MetadataRepositoryRemote
</remote>
<ejb-class>
redicat.mvs.MetadataRepositoryBean
</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Long</prim-key-class>
<reentrant>False</reentrant>
<abstract-schema-name>
MetadataRepository
</abstract-schema-name>
<cmp-field>
<field-name>id</field-name>
</cmp-field>
<cmp-field>
<field-name>type</field-name>
</cmp-field>
<cmp-field>
189
189
190
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
<field-name>dataSourceLocation</field-name>
</cmp-field>
<cmp-field>
<field-name>description</field-name>
</cmp-field>
<cmp-field>
<field-name>resourceLocation</field-name>
</cmp-field>
<primkey-field>id</primkey-field>
<security-identity>
<query>
<query-method>
<method-name>findByType</method-name>
<method-params>
<method-param>
java.lang.String
</method-param>
</method-params>
</query-method>
<ejb-ql>
SELECT DISTINCT OBJECT(m)
FROM MetadataRepository m
WHERE m.type = ?1
</ejb-ql>
</query>
<query>
<query-method>
<method-name>
findByDataSourceLocation
</method-name>
<method-params>
<method-param>
java.lang.String
</method-param>
</method-params>
</query-method>
<ejb-ql>
WHERE m.dataSourceLocation = ?1
</ejb-ql>
</query>
<query>
<query-method>
<method-name>
findByDescription
</method-name>
<method-params>
<method-param>
java.lang.String
</method-param>
</method-params>
</query-method>
<ejb-ql>
190
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
WHERE m.description = ?1
</ejb-ql>
</query>
<query>
<query-method>
<method-name>
findByResourceLocation
</method-name>
<method-params>
<method-param>
java.lang.String
</method-param>
</method-params>
</query-method>
<ejb-ql>
WHERE m.resourceLocation = ?1
</ejb-ql>
</query>
</entity>
[...]

<message-driven>
[...]
</message-driven>
</enterprise-beans>
[...]
</ejb-jar>
Listing A.13: Code-Beispiel eines Deployment-Deskriptors für eine EB
Die Datei jboss.xml umfasst im Falle der Deklaration einer EB lediglich die Deklaration
der Referenzen anderer Beans auf die zu deklarierende EB sowie die Deklaration der EB
selbst und deren Bindung an einen JNDI-Namen. Das XML-Codefragment aus Listing
A.14 zeigt die notwendigen Deklarationen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<!DOCTYPE jboss PUBLIC
"-//JBoss//DTD JBOSS 3.2//EN"
<jboss>
<enterprise-beans>
[...]
<session>
<ejb-name>AK</ejb-name>
<jndi-name>AKHomeRemote</jndi-name>
<ejb-ref>
<ejb-ref-name>MetadataRepository</ejb-ref-name>
<jndi-name>
MetadataRepositoryHomeRemote
</jndi-name>
</ejb-ref>
</session>
[...]
<entity>
<ejb-name>MetadataRepository</ejb-name>
<jndi-name>
MetadataRepositoryHomeRemote
191
191
192
23
24
25
26
27
28
29
30
31
</jndi-name>
</entity>
[...]
<message-driven>
[...]
</message-driven>
</enterprise-beans>
[...]
</jboss>
Listing A.14: Code-Beispiel der Datei jboss.xml für die MetadataRepository-EB
Die vorhergehenden Abschnitte haben je ein Beispiel einer SB, einer MDB und einer EB anhand von JAVA-Code der zu implementierenden Interfaces und Klassen sowie den notwendigen XML-Fragmenten aufgezeigt. Die Interfaces, Klassen und XML-Deskriptoren müssen nun
zusammengefasst und im EJB-Container installiert werden. Das Vorgehen der jar-Erzeugung
und der Installation dieses jars im EJB-Container wird für den speziellen Fall der Nutzung des
JBoss-Applikationsservers im folgenden Abschnitt vorgestellt.
192
B. Installation und Nutzung von
Enterprise-Beans
Zuvor wurde bereits beschrieben, welche Komponenten benötigt werden, um eine EnterpriseBean zu implementieren. Auch Code-Beispiele wurden aufgezeigt. Nun müssen die erzeugten
Beans samt ihrer Deskriptoren in einem EJB-Container installiert werden, damit sie für ClientApplikationen nutzbar sind. Dazu ist zunächst die Erzeugung einer jar-Datei erforderlich, die
dann anhand der Installations-Werkzeuge des EJB-Container-Herstellers im Container installiert (deployed) werden kann.
B.1. Packen und Installieren der Enterprise-Beans
Die Beans müssen in einer jar-Datei vorliegen, um im JBoss-Applikationsserver installiert
werden zu können. Zunächst müssen die Interfaces und Klassen übersetzt werden. Der
Deployment-Deskriptor ejb-jar.xml und die Datei jboss.xml müssen in ein Verzeichnis META-INF gelegt werden. Zur Erzeugung einer jar-Datei kann folgender Aufruf erfolgen:
$ jar cfm ReDiCAt.jar META-INF/ejb-jar.xml META-INF/jboss.xml
GUHomeRemote.class GURemote.class ...
MetadataRepositoryBean.class
wobei alle Interfaces und Klassen in kompilierter Form (.class-Datei) aufgeführt werden
müssen.
Die EJB-Spezifikation verpflichtet den Hersteller des EJB-Containers, die zur Installation einer jar-Datei notwendigen Werkzeuge bereitzustellen. Während der Installation
werden die fehlenden Codefragmente erzeugt. Dazu zählen die Implementationen des
Home- und Remote-Interfaces (EJBHome- bzw. EJBObject-Klasse) und im Falle einer container-managed Entity-Bean auch die Implementierung der konkreten Beanund Persistence-Klasse. Das zuvor erzeugte jar kann im Falle der Nutzung des JBossApplikationsservers ohne ein spezielles Werkzeug durch einfaches Kopieren in das Verzeichnis
$JBOSS HOME/server/default/deploy/ im EJB-Container installiert werden. Auch
die XML-Dateien zur Erzeugung der Message-Queues müssen dort hinterlegt werden. Nach
dem Start des Servers sind die Enterprise-Beans und die Message-Queues einsatzbereit.
Eine Kommunikation mit den Methoden der Enterprise Beans kann aufgrund der vollständigen Kapselung der Bean-Methoden lediglich über das EJBHome bzw. EJBObject-Objekt
durchgeführt werden; die Bean-Klasse selbst ist nicht von außen ansprechbar.
Der folgende Abschnitt erläutert den genauen Ablauf der Nutzung einer Methode einer
Enterprise-Bean durch einen Client.
193
194
K APITEL B - I NSTALLATION UND N UTZUNG VON E NTERPRISE -B EANS
B.2. Nutzung einer Bean durch einen Client
In diesem Abschnitt wird der Ablauf der Nutzung einer Enterprise-Bean-Methode durch einen
Client beispielhaft in kurzer Form aufgezeigt. Wenn ein Client auf einen Dienst, der von einer
Enterprise-Bean angeboten wird, zurückgreifen will, so muss er zunächst mit dem Namensund Verzeichnisdienst des EJB-Containers in Kontakt treten und eine Suchanfrage stellen,
anhand derer die entsprechende Bean lokalisiert werden kann. Diese Kontaktaufnahme wird
über die JNDI-Schnittstelle abgewickelt. Alle im EJB-Container installierten Beans müssen im
Namens- und Verzeichnisdienst verzeichnet sein, dafür ist der Hersteller des EJB-Containers
verantwortlich. Über den Deployment-Deskriptor können Beans mit spezifischen Attributen,
beispielsweise einem JNDI-Namen, versehen werden, anhand derer man sie später auffinden
kann. Zur Suche nach einer Bean kann eines dieser Attribute verwendet werden. Zum Auffinden einer Enterprise-Bean anhand ihres Namens kann der in Listing B.1 dargestellte JAVACode genutzt werden:
1
2
3
4
5
6
Object ref =
jndiContext.lookup("jnp://localhost:1099/GUHomeRemote");
GUHomeRemote home = (GUHomeRemote)
PortableRemoteObject.narrow(ref,GUHomeRemote.class);
GURemote GU = home.create();
Timestamp ts = GU.getGlobalTime();
Listing B.1: Code zum Zugriff auf eine Enterprise-Bean anhand ihres JNDI-Namens
Das jndiContext-Objekt ermöglicht den Zugriff auf den JNDI-Namensdienst des Containers. Zunächst wird das HomeRemote-Objekt erzeugt, anhand dessen ein Remote-Objekt zum
Zugriff instantiiert werden kann. Auf diesem kann dann die gewünschte Methode aufgerufen
werden, in diesem Fall getGlobalTime().
194
C. Ausgaben der Testläufe
Bei Implementierung der ReDiCAt-Architektur wurde darauf geachtet, dass die Kommunikationsflüsse transparent gegenüber einem Benutzer dargelegt werden. Daher geben sämtliche Methoden aller Komponenten bei Aufruf eine Meldung aus, die auf den Aufruf hinweist.
Zudem werden zusätzlich in manchen Fällen noch weitere Informationen ausgegeben. Somit
kann anhand dieser Ausgaben, die in das Log des Applikationsservers geleitet werden, die Sequenz der Methodenaufrufe nachvollzogen werden. Diese gibt einen weiteren Anhaltspunkt
für einen Benutzer, den durch die Implementierung der ReDiCAt-Architektur abgebildeten
Analyse-Ablauf nachzuvollziehen. In den folgenden Abschnitten werden die Ausgaben der
verschiedenen Testläufe der unterschiedlichen Analyse-Abläufe dargestellt.
C.1. Ausgaben des Analyse-Testlaufes zur einfachen
Der Testlauf einer einfachen Klassifikator-Induktion erzeugt die folgenden Ausgaben:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
DEBUG: MVSKBean.onMessage(): ControlMessage: ci
DEBUG: MVSKBean.storeTask(): task stored with id 1.
DEBUG: IMVKBean.executeDataCollection() entered.
DEBUG: IMVKBean.executeDataCollection(): task is ci.
DEBUG: IMVKBean.executeDataCollection(): dsk address:
jnp://localhost:1099/DSKHomeRemote
DEBUG: DSKBean.deliverDataSet() entered.
DEBUG: DSKBean.deliverDataSet(): task string: ci.
DEBUG: DSKBean.deliverDataSet(): td/id address:
jnp://localhost:1099/TDHomeRemote.
DEBUG: TDBean.getTrainingsData() entered.
DEBUG: AnalysisControlBean.onMessage(): trainingsdata received.
DEBUG: AnalysisControlBean.onMessage(): trainingsdata set to EB with
id 1
DEBUG: AnalysisControlBean.onMessage(): sent receipt of trainingsdata
set to be stored.
DEBUG: IMVKBean.executeDataCollection(): sent command to execute
classifier collection.
DEBUG: MVSKBean.loadTask(): task with id 1 loaded.
DEBUG: MVSKBean.onMessage(): trainingsdata set delivery receipt
reveiced.
DEBUG: IMVKBean.executeClassifierCollection() entered.
DEBUG: IMVKBean.executeClassifierCollection(): bsk address:
DEBUG: BSKBean.deliverClassifierSet(): no classifiers to be selected.
195
196
K APITEL C - AUSGABEN DER T ESTL ÄUFE
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
DEBUG: AnalysisControlBean.onMessage(): EB with pk 1 already exists.
Using this one.
DEBUG: AnalysisControlBean.onMessage(): classifier set to EB with
id 1
DEBUG: MVSKBean.onMessage(): classifier delivery receipt reveiced.
DEBUG: AnalysisControlBean.onMessage(): sent receipt of classifier
set to be stored.
DEBUG: IMVKBean.executeClassifierCollection(): sent command to
execute analysis.
DEBUG: IMVKBean.executeAnalysisTask() entered.
DEBUG: IMVKBean.executeAnalysisTask(): iik address:
jnp://localhost:1099/IIKHomeRemote
DEBUG: IIKBean.induceClassifier() entered.
DEBUG: IIKBean.induceClassifier(): EB with pk 1 already exists.
Using this one.
DEBUG: IIKBean.induceClassifier(): induced Classifier based on
SelectedDataSet retreived from the entity bean
ContentResourceStorage. Task was simple classifier induction.
DEBUG: VKControlBean.onMessage() entered.
DEBUG: VKControlBean.onMessage(): classifier received.
DEBUG: VKBean.utiliseResource() entered.
DEBUG: VKBean.utiliseResource(): Utilisation is both.
DEBUG: VKBean.utiliseResource(): initiate storage and visualisation.
RESULT: VKBean.visualizeResource(): ================================
beschreibt.
RESULT: VKBean.visualizeResource(): Location:
RESULT: VKBean.visualizeResource(): ================================
beschreibt.
196
C.2 AUSGABEN DES A NALYSE -T ESTLAUFES ZUR
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
INKREMENTELLEN K LASSIFIKATOR -I NDUKTION
DEBUG: VKBean.createAKMetadata() entered.
DEBUG: VKBean.createAKMetadata(): sent message with AKMetadata.
DEBUG: MVSKBean.onMessage(): cleaning up, inserting newly created
ContentResource via AK component...
DEBUG: MVSKBean.deleteTask(): task with id 1 deleted.
DEBUG: MVSKBean.deleteContentResourceStorageBean():
ContentResourceStorageBean with id 1 deleted.
with values:
DEBUG: AKBean.storeContentResourceMetadata(): contentResourceLocation:
DEBUG: AKBean.storeContentResource(): metadata set stored in eb with
id 1108758777160.
Listing C.1: Ausgaben des Testlaufes der einfachen Klassifikator-Induktion
C.2. Ausgaben des Analyse-Testlaufes zur inkrementellen
Der Testlauf einer inkrementellen Klassifikator-Induktion erzeugt die folgenden Ausgaben:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
DEBUG: MVSKBean.onMessage(): ControlMessage: ici
DEBUG: IMVKBean.executeDataCollection() entered.
DEBUG: IMVKBean.executeDataCollection(): task is ici.
DEBUG: IMVKBean.executeDataCollection(): dsk address:
DEBUG: DSKBean.deliverDataSet(): task string: ici.
DEBUG: AnalysisControlBean.onMessage(): trainingsdata set to EB with
id 1
DEBUG: AnalysisControlBean.onMessage(): sent receipt of trainingsdata
set to be stored.
DEBUG: IMVKBean.executeDataCollection(): sent command to execute
received.
197
197
198
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
DEBUG: AnalysisControlBean.onMessage(): EB with pk 1 already exists.
Using this one.
id 1
DEBUG: MVSKBean.onMessage(): classifier delivery receipt received.
set to be stored.
execute analysis.
DEBUG: IMVKBean.executeAnalysisTask(): iik address:
Using this one.
SelectedDataSet and ClassifierSet retreived from the entity bean
ContentResourceStorage. Task was incremental classifier induction.
beschreibt.
198
C.3 AUSGABEN DES A NALYSE -T ESTLAUFES EINES M ETA -L ERN -VORGANGES
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
beschreibt.
with values:
contentResourceLocation: jnp://localhost:1099/KRHomeRemote
with id 1108769465393
Listing C.2: Ausgaben des Testlaufes der inkrementellen Klassifikator-Induktion
C.3. Ausgaben des Analyse-Testlaufes eines
Meta-Lern-Vorganges
Der Testlauf eines Meta-Lern-Vorganges erzeugt die folgenden Ausgaben:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
DEBUG: MVSKBean.onMessage(): ControlMessage: ml
199
199
200
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
id 1
set to be stored.
DEBUG: AnalysisControlBean.onMessage(): EB with pk 1 already
exists. Using this one.
id 1
execute analysis.
DEBUG: IMVKBean.executeAnalysisTask(): ml address:
jnp://localhost:1099/MLHomeRemote
DEBUG: MLBean.executeMetaLearnTask() entered.
DEBUG: MLBean.executeMetaLearnTask(): EB with pk 1 already exists.
Using this one.
DEBUG: MLBean.executeMetaLearnTask(): induced global Model based
ClassifierSet retreived from the entity bean
ContentResourceStorage. Task was metalearn task.
DEBUG: VKControlBean: globalModel received.
DEBUG: VKBean.utiliseResource(): initiate storage and
visualisation.
Implementierung eines Datensatzes, der ein globales Modell
beschreibt.
jnp://localhost:1099/MLHomeRemote
200
C.4 AUSGABEN DES A NALYSE -T ESTLAUFES EINER
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
NAIVEN
K LASSIFIKATOR -A NWENDUNG
Implementierung eines Datensatzes, der ein globales Modell
beschreibt.
set with values:
DEBUG: AKBean.storeContentResourceMetadata(): type: globalModel
globales Modell beschreibt.
with id 1108768360036
Listing C.3: Ausgaben des Testlaufes eines Meta-Lern-Vorganges
C.4. Ausgaben des Analyse-Testlaufes einer naiven
Klassifikator-Anwendung
Der Testlauf zur naiven Anwendung eines Klassifikators erzeugt diese Ausgaben:
1
2
3
4
5
6
7
8
9
10
11
DEBUG: MVSKBean.onMessage(): ControlMessage: naive
DEBUG: AMVKBean.executeDataCollection() entered.
DEBUG: AMVKBean.executeDataCollection(): task is naive.
DEBUG: AMVKBean.executeDataCollection(): dsk address:
DEBUG: DSKBean.deliverDataSet(): task string: naive.
jnp://localhost:1099/IDHomeRemote.
DEBUG: IDBean.getInstanceData() entered.
201
201
202
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
DEBUG: AnalysisControlBean: instancedata received.
DEBUG: AnalysisControlBean.onMessage(): instancedata set to EB
with id 1
DEBUG: AMVKBean.executeDataCollection(): sent command to execute
instancedata set to be stored.
DEBUG: MVSKBean.onMessage(): instancedata set delivery receipt
received.
with id 1
set to be stored.
DEBUG: AMVKBean.executeClassifierCollection(): sent command to
execute analysis.
DEBUG: AMVKBean.executeAnalysisTask(): kk address:
jnp://localhost:1099/KKHomeRemote
DEBUG: KKBean.classifyDataSet entered.
DEBUG: KKBean.classifyDataSet(): EB with pk 1 already exists.
Using this one.
DEBUG: KKBean.classifyDataSet(): executed Classification based
on SelectedDataSet and Classifier retreived from the entity
bean ContentResourceStorage. Task was naive classification.
DEBUG: VKControlBean.onMessage(): classification ResultDataSet
received.
202
C.4 AUSGABEN DES A NALYSE -T ESTLAUFES EINER
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
NAIVEN
K LASSIFIKATOR -A NWENDUNG
myUser
MyPassword
DEBUG: MVSKBean.onMessage(): cleaning up, inserting newly
created ContentResource via AK component...
set with values:
with id 1108772119124
Listing C.4: Ausgaben des Testlaufes einer naiven Klassifikator-Anwendung label
203
203
204
C.5. Ausgaben des Analyse-Testlaufes der
SG-Klassifikation
Der Testlauf einer Klassifikation durch die Ableitung von Selection Graphs aus einem Klassifikator und anschließender Wandlung dieser zu Datenbank-Abfragen erzeugt folgende Ausgaben:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
DEBUG: MVSKBean.onMessage(): ControlMessage: sg
DEBUG: AMVKBean.executeDataCollection() entered.
DEBUG: AMVKBean.executeDataCollection(): sent command to execute
with id 1
DEBUG: AMVKBean.executeClassifierCollection(): sent command
received.
DEBUG: AMVKBean.executeAnalysisTask(): sgak address:
jnp://localhost:1099/SGAKHomeRemote
DEBUG: SGAKBean.executeSelectionGraphDerivation() entered.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): using as
receipt component address.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): using
jnp://localhost:1099/IDHomeRemote as data source component.
DEBUG: SGAKBean.executeSelectionGraphDerivation(): executed
selection graph derivation based on Classifier retreived from
the entity bean ContentResourceStorage. Task was sg
classification.
DEBUG: DBAGKBean.executeQueryProcessing() entered.
DEBUG: DBAGKBean.executeQueryProcessing(): Generated
classification result dataset.
DEBUG: VKControlBean.onMessage(): classification ResultDataSet
received.
204
C.5 AUSGABEN DES A NALYSE -T ESTLAUFES DER SG-K LASSIFIKATION
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
DEBUG: VKBean.utiliseResource(): initiate storage and
visualisation.
myUser
MyPassword
set with values:
205
205
206
110
111
112
113
114
115
116
117
118
with id 1108772273757
Listing C.5: Ausgaben des Testlaufes einer Klassifikation mit Selection Graphs
C.6. Ausgaben des Analyse-Testlaufes einer
Klassifikator-Wartung
Diese Ausgaben wurden durch einen Testlauf einer Klassifikator-Wartung erzeugt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
DEBUG: MVSKBean.onMessage(): ControlMessage: maintenance
DEBUG: WVSKBean.onMessage(): using IVK address
jnp://localhost:1099/IVKHomeRemote.
DEBUG: IVKBean.invalidateClassifier(): kr address:
DEBUG: IVKBean.invalidateClassifier(): using global clock to
generate invalidation timestamp.
DEBUG: GUBean.getGlobalTime: global timestamp is:
2005-02-19 01:19:11.016.
DEBUG: KRBean.setClassifier(): classifier stored:
Classifier invalidated by IVK component.
DEBUG: IVKBean.invalidateClassifier(): stored invalidated
classifier at component kr with address:
jnp://localhost:1099/KRHomeRemote and value of
tte: 2005-02-19 01:19:11.016.
DEBUG: WMVKBean.executeDataCollection() entered.
DEBUG: WMVKBean.executeDataCollection(): task is maintenance.
DEBUG: WMVKBean.executeDataCollection(): dsk address:
DEBUG: DSKBean.deliverDataSet(): task string: maintenance.
DEBUG: AnalysisControlBean.onMessage(): trainingsdata set to EB
with id 1
trainingsdata set to be stored.
received.
DEBUG: WMVKBean.executeDataCollection(): sent command to execute
206
C.6 AUSGABEN DES A NALYSE -T ESTLAUFES EINER K LASSIFIKATOR -WARTUNG
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
DEBUG: WMVKBean.executeClassifierCollection() entered.
DEBUG: WMVKBean.executeClassifierCollection(): bsk address:
with id 1
received.
DEBUG: WMVKBean.executeClassifierCollection(): sent command
DEBUG: WMVKBean.executeAnalysisTask() entered.
DEBUG: WMVKBean.executeAnalysisTask(): iik address:
Using this one.
SelectedDataSet and ClassifierSet retreived from the entity
bean ContentResourceStorage. Task was classifier maintenance.
beschreibt.
207
207
208
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
beschreibt.
set with values:
with id 1108772353406
Listing C.6: Ausgaben des Testlaufes einer Klassifikator-Wartung
208
Glossar
Data Mining: ∼ bezeichnet den Prozess des automatischen Erzeugens eines Modelles, das
maßgebliche Entwicklungen und Muster in Quelldaten beschreibt, die von intelligenten Analyse-Algorithmen identifiziert werden. ∼ wird dabei als einer von mehreren
Schritten im ↑KDD-Prozess verstanden.
Data Warehouse System: Ein ∼ ist ein Informationssystem, welches alle für den DWHProzess benötigten Komponenten bereitstellt. Zu diesen Komponenten zählen Datenbeschaffungsbereich und Analyse, Metadatenmanagement, DWH-Management und die
Basisdatenbank, das eigentliche Data Warehouse und das Repository.
Data Warehouse: ∼ ist eine Sammlung von themenorientierten, integrierten, nichtflüchtigen
und zeitbeständigen Daten zur Unterstützung von Management-Entscheidungen in einem Unternehmen.
Datenvorverarbeitung: Die ∼ besteht aus verschiedenen Schritten, die Daten aufbereiten,
damit diese bereinigt, integriert, aggregiert und transformiert vorliegen und somit für
verschiedene nachfolgende Zwecke wie z.B. die Speicherung in ↑Data Warehouses
oder die Analyse durch verschiedene Algorithmen vorbereitet und geeignet sind.
Distributed Data Mining: ∼ bezeichnet den Prozess des ↑Data Mining auf verteilten Datenquellen.
Enterprise JavaBeans: ∼ sind in einem verteilten Szenario serverseitige Komponenten, die
in der Komponenten-Architektur der Enterprise JavaBeans (EJB) zum Einsatz kommen. Enterprise-Beans definieren die Anwendungslogik, auf die die Client-Programme
zugreifen.
Enterprise-Beans: ↑ bezeichnen in einem verteilten Szenario serverseitige Komponenten,
die in der Komponenten-Architektur der ↑Enterprise JavaBeans zum Einsatz kommen.
Enterprise-Beans definieren die Anwendungslogik, auf die die Client-Programme zugreifen.
Entity-Bean: Eine ∼ (EB) ist eine Enterprise-Bean, die zur Speicherung von Daten genutzt
werden kann. Sie ist innerhalb eines Containers persistent und kann in vielen Instanzen
mit jeweils eigenen Werten vorliegen.
Entscheidungsbaum: Ein ∼ ist eine Baumstruktur, die in ihren Knoten Attribute (wie z.B.
Gehalt<50000) beinhaltet. Die von einem Knoten ausgehenden Kanten beschreiben
die möglichen Alternativen (z.B. Ja oder Nein). Die Blätter stellen Zielklassen dar
(z.B. Großverdiener). Ein Entscheidungsbaum dient der Überprüfung von Attributen
und Werten und kann somit zur Klassifizierung genutzt werden.
Entwicklungsmuster: Ein ∼, auch als Design Pattern bekannt, definiert ein programmiersprachenunabhängiges Schema zur Verfeinerung von Subsystemen oder Komponenten
eines Software-Systemes oder der Beziehungen dieser untereinander.
209
210
G LOSSAR
HTML: ∼ steht für HyperT extM arkupLanguage und bezeichnet eine Sprache zur Beschreibung von formatiertem Text.
HTTP: ∼ steht für HyperT extT ransf erP rotocol und bezeichnet ein Protokoll zum Transport von ↑HTML-Dokumenten.
IIOP: Internet Inter-ORB Protocol: wird zur Kommunikation zwischen CORBA ORBs genutzt. Nähere Informationen zu IIOP und CORBA siehe [OMG02].
J2EE: Java 2 Platform, Enterprise Edition: definiert den Standard zur Entwicklung von komponentenbasierten, verteilten Unternehmensanwendungen.
J2SE: Java 2 Platform, Standard Edition: Diese beinhaltet eine vollständige Umgebung zur
Anwendungsentwicklung auf dem Desktop und auf Servern.
Java RMI: Java Remote Method Invocation: ermöglicht es, verteilte Java-Anwendungen zu
entwerfen, in denen Methoden entfernter Java-Objekte auf anderen Maschinen aufgerufen werden können. Näheres dazu siehe [Sun04j].
Java Server Pages: ∼ bezeichnen dynamische Webseiten auf Basis des ↑J2EE-Konzeptes.
JavaMail: JavaMail: bietet ein plattform- und protokollunabhängiges Framework zur Erzeugung von Email- und Messaging-Anwendungen.
JAXP: Java API for XML Processing: erlaubt es Anwendungen, XML-Dokumente unabhängig von einer speziellen Implementation eines XML-Prozessors zu parsen und
zu transformieren.
JDBC: Java Database Connectivity: bietet Zugriff auf verschiedene SQL-Datenbanken.
JMS: Java Message Service: erlaubt J2EE-Komponenten die Erzeugung, das Versenden und
Empfangen sowie das Lesen von Nachrichten.
JNDI: Java Naming and Directory Interface: bietet eine einheitliche Schnittstelle zu verschiedenen Namens- und Verzeichnisdiensten basierend auf Java.
JTA: Java Transaction API: spezifiziert eine Standard-Schnittstelle zwischen einem Transaktionsmanager und den Komponenten eines verteilten Systemes.
Klassifikation: Die ∼ ist ein Prozess, der aus zwei Schritten besteht. Im ersten Schritt wird
durch Analyse von Datentupeln ein Modell erzeugt, das eine vorgegebene Menge von
Datenklassen oder Konzepten beschreibt. Im zweiten Schritt wird das Modell genutzt,
um Daten einer der gefundenen Klassen zuzuordnen.
Knowledge Discovery in Databases: ∼ bezeichnet den nicht trivialen Prozess der Identifikation valider, neuartiger, potentiell nützlicher und klar verständlicher Muster in Daten.
Der Prozess beinhaltet dabei Schritte von der ursprünglichen Datenauswahl bis hin zur
Interpretation der gefundenen Muster und der folgenden Umsetzung.
Message-Driven-Bean: Eine ∼ (MDB) ist eine Enterprise-Bean, die auf Nachrichten reagiert.
Wird eine Nachricht an eine ↑MessageQueue oder ein ↑Topic gesendet, welche bzw.
welches von der MDB observiert wird, so wird die Methode onMessage() der MDB
ausgeführt.
Message-Queue: Eine ∼ ist eine Warteschlange, an die Nachrichten verschickt werden
können. Eine ↑Message-Driven-Bean kann eine solche Warteschlange observieren und
auf Nachrichten reagieren, die an diese Warteschlange gesendet wurden.
210
G LOSSAR
211
Meta-Lerner: Ein ∼ ist in der Lage, verteilt erzeugte, verschiedene Ergebnisse von unterschiedlichen ↑Data Mining-Algorithmen zu einem Gesamtergebnis zusammenzusetzen. So können beispielsweise auf verteilten Datenbeständen jeweils lokal Klassifikatoren generiert werden, die dann in zentraler Instanz von einem Meta-Lerner zu einem
globalen Klassifikator zusammengesetzt werden.
Privacy Preserving Data Mining: ∼ ist eine Form des ↑Data Mining, bei der die Wahrung
datenschutzrechtlicher Aspekte der zu analysierenden Daten Beachtung findet.
ReKlaMe: ∼ bezeichnet ein Dissertationsprojekt, dessen Ziel es ist, Klassifikationen auf verteilten Data Warehouses (siehe ↑Distributed Data Mining) direkt auf den relationalen
Teildaten zu betreiben, ohne eine logische Schemaintegration durchführen zu müssen.
Servlet: Ein ∼ ist im Rahmen des ↑J2EE-Konzeptes ein Java-Objekt, das von einem WebServer Anfragen von dessen Clients bekommt, um diese dynamisch zu bearbeiten und
zu beantworten.
Session-Bean: Eine ∼ ist eine Enterprise-Bean, die eine Menge an Geschäftsmethoden zur
Verfügung stellt, die von Client-Applikationen oder anderen ↑Enterprise-Beans genutzt
werden können.
Software-Entwicklungsmuster: ↑ Entwicklungsmuster.
Topic: Ein ∼ ist eine Art Adresse, an die eine Nachricht geschickt werden kann. Mehrere
↑Message-Driven-Beans können Nachrichten an ein Topic empfangen.
Web-Container: Ein ∼ ist eine Laufzeitumgebung für ↑Servlets und ↑Java Server Pages, die
von einem ↑J2EE-Server bereitgestellt wird.
Wissensbasis: Die ∼ beinhaltet Muster, die von ↑Data Mining-Algorithmen gefunden und
anschließend vom Anwender als nützlich klassifiziert wurden.
XML: ∼ steht für ExtensibleM arkupLanguage und bezeichnet ein semi-strukturiertes
Daten-Austauschformat.
211
212
G LOSSAR
212
Tabellenverzeichnis
3.1. Gegenüberstellung der drei Bean-Typen (nach [DP02]) . . . . . . . . . . . . . 44
5.1. Einteilung der Komponenten der ReKlaMe-Gesamt-Architektur in zentral und dezentral angebundene Kompon
7.1. Gegenüberstellung von Bean-Typen und Bean-Komponenten (nach [DP02]) . . 159
7.2. Zuteilung der implementierten Komponenten zu den Bean-Typen . . . . . . . . 159
213
214
TABELLENVERZEICHNIS
214
Abbildungsverzeichnis
1.1. Analyse-Prozess im ReKlaMe-Ansatz [Tap04] . . . . . . . . . . . . . . . . . .
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
Der KDD-Prozess (nach [HK00]) . . . . . . . . . . . . . . . . .
Ein beispielhafter Entscheidungsbaum (nach [HK00]) . . . . . . .
Paralleles Data Mining auf einem einzelnen System (nach [Tal03])
Task-parallelisiertes DDM (nach [Tal03]) . . . . . . . . . . . . .
Task-parallelisierte Klassifikation (nach [Tal03]) . . . . . . . . . .
Daten-parallelisiertes DDM (nach [Tal03]) . . . . . . . . . . . . .
Daten-parallelisierte Klassifikation (nach [Tal03]) . . . . . . . . .
3.1.
3.2.
3.3.
3.4.
3.5.
Beispiel einer Architektur für eine Klassifikationsanalyse . . . . . . . . . . . . 24
Überblick über verschiedene komponentenbasierte Architektur-Ansätze und deren Beziehungen untereinander
Das ISO-OSI-Referenzmodell als Beispiel für eine Multi-Layer-Architektur (nach [KB94]) 29
Einordnung der EJB-Architektur in den J2EE-Kontext (nach [DP02]) . . . . . . 38
Gesamtüberblick über die EJB-Architektur (nach [DP02]) . . . . . . . . . . . . 39
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
4.10.
4.11.
4.12.
4.13.
4.14.
Identifizierte Abläufe im Rahmen von ReKlaMe: Induktion, Klassifikation und Wartung 50
Lerner auf a) einer Datenquelle und b) inkrementell auf einer Datenquelle und einem Basisklassifikator 51
Meta-Lerner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Verteilte Klassifikation ohne virtuelle oder physische Integration der Instanzen . 52
Verteilte Klassifikation ohne virtuelle oder physische Integration der Instanzen für Klassifikatoren, die auf meh
Verteilte Klassifikation durch Erzeugung von Selection Graphs und Wandeln in Datenbankabfragen 54
Wartung von Basisklassifikatoren: Invalidierung, Aktualisierung und Neugenerierung 55
Ablauf einer einfachen Klassifikator-Induktion . . . . . . . . . . . . . . . . . 63
Ablauf einer inkrementellen Klassifikator-Induktion . . . . . . . . . . . . . . . 64
Ablauf des Meta-Lernens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Ablauf einer Klassifikator-Anwendung . . . . . . . . . . . . . . . . . . . . . . 66
Ablauf einer verteilten Klassifikation durch Ableitung von Selection Graphs und deren Wandlung in Datenbank
Phase der (inkrementellen) Aktualisierung/Neugenerierung eines Klassifikators im Ablauf der Wartung 68
Phase der Erweiterung eines Klassifikators durch einen Meta-Lerner im Ablauf der Wartung 69
5.1.
5.2.
5.3.
5.4.
5.5.
Architektur des ReKlaMe-Projektes auf hoher Abstraktionsebene
Architektur der Klassifikator-Induktion . . . . . . . . . . . . .
Architektur der Klassifikator-Anwendung . . . . . . . . . . . .
Architektur der Klassifikator-Wartung . . . . . . . . . . . . . .
Gesamt-Architektur des ReKlaMe-Projektes . . . . . . . . . . .
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
Klassendiagramm der Interfaces zur Abbildung der ADT . . . . . . . . . . . . 99
Klassendiagramm der Interfaces und Klassen zur Abbildung der ADT . . . . . 111
Klassendiagramm der Metadaten zur Steuerung der Aktualisierungs-Komponente AK113
Klassendiagramm der Metadaten zur Basisklassifikator-Selektion . . . . . . . . 115
Klassendiagramm der Metadaten zur Daten-Selektion . . . . . . . . . . . . . . 117
Klassendiagramm der Metadaten zur Steuerung der Datenbank-Abfrage-Generierungs-Komponente 119
215
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
8
11
17
17
18
18
18
74
76
80
83
84
216
A BBILDUNGSVERZEICHNIS
6.7.
6.8.
6.9.
6.10.
6.11.
6.12.
6.13.
6.14.
6.15.
6.16.
6.17.
Klassendiagramm der Metadaten zur Steuerung der Invalidierungs-Komponente 121
Klassendiagramm der Metadaten zur Steuerung der Benutzungsschnittstellen-Komponente 123
Klassendiagramm der Metadaten zur Steuerung der Task-Analyse-Komponente 125
Klassendiagramm der Metadaten zur Steuerung der Metadaten-Verwaltungs-/Steuerungs-Komponent
Klassendiagramm der Metadaten zur Steuerung der Verwertungs-Komponente . 130
Klassendiagramm der Klassen und Interfaces zur Repräsentation der ADT zur Parametrisierung und
Sequenz-Diagramm der Methodenaufrufe zur Durchführung einer einfachen Klassifikator-Induktion 1
Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines Meta-Lern-Prozesses145
Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines Analyse-Ablaufes der naiven Klas
Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines Analyse-Ablaufes der Klassifikatio
Sequenz-Diagramm der Methodenaufrufe zur Durchführung eines Analyse-Ablaufes der Klassifikato
7.1. Gespeicherte Metadaten über den durch den Testlauf neu erzeugten Klassifikator 164
7.2. Gespeicherte Metadaten über das durch den Testlauf neu erzeugte globale Modell165
7.3. Gespeicherte Metadaten über das durch den Testlauf zur naiven Klassifikator-Anwendung neu erzeug
216
Symbol-Verzeichnis
ID3-A LGORITHMUS
a = {a1 , a2 , . . . , an }
Werte, die A annehmen kann
A
Ein Attribut der Elemente aus S
C
Menge von Klassen von Datensätzen
E(A)
Entropie zur Klassifikation anhand des Attributes A
Gain(A)
information gain, Menge an Informationen, die durch Partitionierung gewonnen wurde
I
zu erwartende Information aus Partitionierung von Trainingsdaten
p
Wahrscheinlichkeit
s = {s1 , s2 , . . . , sn }
Datensätze ∈ S
S
Menge von Datensätzen
Si
Menge der Datensätze aus S, die in Klasse Ci enthalten sind
D EFINITIONEN
VON
AGENTEN
A
Menge von Agenten (A ⊆ O)
B
Menge von Beziehungen, die Objekte ∈ O miteinander verbinden
O
Menge von situierten Objekten, die von Agenten wahrgenommen,
erzeugt, modifiziert und gelöscht werden können
Op
Menge von Operationen, mit denen Agenten Objekte empfangen,
erzeugen, konsumieren, verändern und löschen können
U
Umwelt eines Agenten
S YMBOLE
DES
AUSF ÜHRUNGSMODELLES
C
Menge von Klassen von Datensätzen
D
Menge von Datensätzen/Instanzen
ϕ
Menge aller Basisklassifikatoren
Φ
Menge globaler Klassifikatoren
i
zu klassifizierende Instanz ∈ D
k, k1 , k2 , . . . , kn
Basisklassifikatoren ∈ ϕ
217
218
S YMBOL -V ERZEICHNIS
S YMBOLE
DES
AUSF ÜHRUNGSMODELLES (F ORTSETZUNG )
kinv
invalidierter Basisklassifikator ∈ ϕ
kT
Basisklassifikator ∈ ϕ erweitert durch Trainingsdatenmenge T
kϕ
globaler Klassifikator ∈ Φ, der von einem Meta-Lerner auf Basis
der Basisklassifikatoren k1 , k2 , . . . , kn ∈ ϕ erzeugt wurde
M
Menge von Metadatenmengen
m
Metadatenmenge ∈ M
Q
Menge von Datenbankabfragen
S
Menge von Selection Graphs
T
Menge von Trainingsdatenmengen ∈ D × C
t
Trainingsdatenmenge ∈ T
z
Zielklasse ∈ C
218
Abkürzungs-Verzeichnis
A LLGEMEINE A BK ÜRZUNGEN
DDM
Distributed Data Mining
DM
Data Mining
DWH
Data Warehouse
DWS
Data Warehouse System
EB
Entity-Bean
EJB
Enterprise JavaBeans
HTML
HyperText Markup Language
HTTP
HyperText Transfer Protocol
IIOP
Internet Inter-ORB Protocol
J2EE
Java 2 Platform, Enterprise Edition
J2SE
Java 2 Platform, Standard Edition
JSP
Java Server Pages
JAXP
Java API for XML Processing
JDBC
Java Database Connectivity
JMS
Java Message Service
JNDI
Java Naming and Directory Interface
JTA
Java Transaction API
KDD
Knowledge Discovery in Databases
MDB
Message-Driven-Bean
PPDM
Privacy Preserving Data Mining
ReDiCAt
ReKlaMe Distributed Classification Architecture
ReKlaMe
Klassifikation relationaler und verteilter Daten am Beispiel des
Kundenmanagements
RMI
Remote Method Invocation
SB
Session-Bean
XML
Extensible Markup Language
219
220
A BK ÜRZUNGS -V ERZEICHNIS
O PERATOREN
UND
A BL ÄUFE
DES
AUSF ÜHRUNGSMODELLES
BSO
Basisklassifikator-Selektions-Operator
DSO
Daten-Selektions-Operator
IO
Induktions-Operator
IIO
Inkrementeller Induktions-Operator
IN D
Ablauf der einfachen Induktion eines Basisklassifikators
IN O
Basisklassifikator-Invalidierungs-Operator
KO
Klassifikations-Operator
M LO
Meta-Lern-Operator
SGO
Operator zur Selection-Graph-Ableitung
SGT O
Operator zur Selection-Graph-Transformation in Datenbankabfragen
WO
Wrapping-Operator zur relationalen Datenbank
M ODULE , U NTERMODULE
UND
KOMPONENTEN
DER
A RCHITEKTUR
BSI
Modul zur Benutzung/Steuerung/Interaktion
BSI:Eingabe
Untermodul zur Bearbeitung der Benutzer-Eingaben
BSI:Eingabe:BS
Komponente zur Schaffung einer Schnittstelle gegenüber einem
Benutzer. Hier werden Analyse-Abläufe parametrisiert
BSI:Eingabe:TA
Komponente zur Extraktion und Identifikation des anzuwendenden Analyse-Ablaufes (Tasks)
BSI:Ausgabe
Untermodul zur Verwertung der erzeugten Analyse-Ergebnisse
BSI:Ausgabe:EV
Abstrakte Komponente zur Zusammenfassung der Komponenten
zur Verarbeitung der Analyse-Ergebnisse
BSI:Ausgabe:EV:S Komponente
Ergebnisse
zur
persistenten
Speicherung
der
Analyse-
BSI:Ausgabe:EV:V Komponente zur Visualisierung der Analyse-Ergebnisse gegenüber einem Benutzer
BSI:Ausgabe:VK
Komponente zur Steuerung der Verwertung der Ergebnisse einer
Analyse
MVS
Modul zur Verwaltung von Metadaten und zur Steuerung der
Abläufe
MVS:MVSK
Abstrakte Komponente zur Steuerung der für die verschiedenen Analyse-Abläufe benötigten Metadaten-VerwaltungsKomponenten
MVS:MVSK:AMVK
Komponente zur Verwaltung der Metadaten für den Ablauf der
Anwendung von Klassifikatoren und dessen Steuerung
MVS:MVSK:IMVK
Induktion von Klassifikatoren und dessen Steuerung
220
221
M ODULE , U NTERMODULE
UND
KOMPONENTEN
DER
A RCHITEKTUR (F ORTSETZUNG )
MVS:MVSK:WMVK
Wartung von Klassifikatoren und dessen Steuerung
MVS:AK
Komponente zur Speicherung von Metadaten über Klassifikatoren
und Klassifikationsergebnisse, die durch einen Analyse-Ablauf
neu erzeugt wurden
MVS:GU
Komponente zur Bereitstellung eines architekturweit gültigen, aktuellen Zeitstempels
AA
Modul zur Durchführung von Analysen
AA:BSK
Komponente zur Selektion von Basisklassifikatoren
AA:DBAGK
Komponente zur Generierung von Datenbank-Abfragen aus Selection Graphs
AA:DQ
Untermodul zur Verwaltung der Datenquellen und Datensenken
AA:DQ:ID
Komponente zum Zugriff auf Datenquelle für Instanzdaten
AA:DQ:KE
Komponente zum Zugriff auf Datenquelle für KlassifikationsErgebnisse
AA:DQ:KR
Komponente zum Zugriff auf Datenquelle für Klassifikatoren
AA:DQ:TD
Komponente zum Zugriff auf Datenquelle für Trainingsdaten
AA:DSK
Komponente zur Selektion von Trainings- oder Instanzdatensätzen
AA:IVK
Komponente zur Invalidierung von Klassifikatoren durch
Transaktionszeit-Zeitstemplung
AA:KV
Abstrakte Komponente zur Zusammenfassung von Komponenten
zur Verarbeitung von Klassifikatoren
AA:KV:(I)IK
Komponente zur (inkrementellen) Induktion von Klassifikatoren
AA:KV:KK
Komponente zur Anwendung von Klassifikatoren
AA:ML
Komponente zur Durchführung eines Meta-Lern-Prozesses
AA:SGAK
Komponente zur Ableitung von Selection Graphs aus Basisklassifikatoren
221
222
222
Listingverzeichnis
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
6.10.
6.11.
6.12.
6.13.
6.14.
6.15.
6.16.
6.17.
6.18.
6.19.
6.20.
6.21.
6.22.
6.23.
6.24.
6.25.
6.26.
Konstruktor SimpleClassificationTask.java . . . .
Konstruktor SimpleClassifier.java . . . . . . . .
Konstruktor SimpleClassifierLocation.java . . . .
Konstruktor SimpleComponentAddress.java . . .
Konstruktor SimpleContentResourceLocation.java
Konstruktor SimpleDataSet.java . . . . . . . . .
Konstruktor SimpleInductionTask.java . . . . . .
Konstruktor SimpleMaintenanceTask.java . . . .
Konstruktor SimpleParameterSet.java . . . . . .
Konstruktor SimpleQueryMetadata.java . . . . .
Konstruktor SimpleResultDataSet.java . . . . . .
Konstruktor SimpleResultDataSetLocation.java .
Konstruktor SimpleSelectedDataSet.java . . . . .
Konstruktor SimpleTimestampMetadata.java . . .
Konstruktor SimpleAKMetadata.java . . . . . . .
Konstruktor SimpleBSKMetadata.java . . . . . .
Konstruktor SimpleDSKMetadata.java . . . . . .
Konstruktor SimpleDBAGKMetadata.java . . . .
Konstruktor SimpleIVKMetadata.java . . . . . .
Konstruktor SimpleBSMetadata.java . . . . . . .
Konstruktor SimpleTAMetadata.java . . . . . . .
Konstruktor SimpleMVSKMetadata.java . . . . .
Konstruktor SimpleVKMetadata.java . . . . . . .
Konstruktor SimpleClassificationMetadata.java .
Konstruktor SimpleInductionMetadata.java . . .
Konstruktor SimpleMaintenanceMetadata.java . .
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
7.8.
7.9.
Aufruf der main()-Methode der Klasse JavaUserInterface . . . . . . . 160
Erzeugung eines SimpleInductionTask-Objektes . . . . . . . . . . . . . 161
Ausgabe der Implementierung der Architektur zur Visualisierung eines neu induzierten Klassifikators im Falle
Ausgabe der Implementierung der Architektur zur Speicherung eines neu induzierten Klassifikators im Falle ei
Ausgabe der Implementierung der Architektur zur Speicherung des Metadaten-Objektes über den neu induzier
Ausschnitt der Ausgabe des Testlaufes einer naiven Klassifikator-Anwendung . 165
Ausschnitt der Ausgabe des Testlaufes zur Speicherung der Metadaten über das erzeugte Klassifikationsergebn
Ausschnitt der Ausgabe des Testlaufes der Selection Graph-Klassifikation . . . 167
Ausschnitt der Ausgabe des Testlaufes der Klassifikator-Wartung: Invalidierung des zu wartenden Klassifikator
A.1.
A.2.
A.3.
A.4.
A.5.
A.6.
Code des HomeRemote-Interfaces der GU-Bean . . . . . . . . . . . . . . . . . 177
Code des Remote-Interfaces der GU-SB . . . . . . . . . . . . . . . . . . . . . 178
Code der Bean-Klasse der GU-SB . . . . . . . . . . . . . . . . . . . . . . . . 178
Code-Beispiel eines Deployment-Deskriptors . . . . . . . . . . . . . . . . . . 180
Code-Beispiel der Datei jboss.xml . . . . . . . . . . . . . . . . . . . . . . 180
XML-Code zur Einrichtung der controlQueue in einem JBoss-EJB-Container181
223
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
100
101
102
102
103
103
104
106
107
107
107
108
109
109
114
116
118
120
122
124
127
129
131
134
134
134
224
L ISTINGVERZEICHNIS
A.7. Code der Bean-Klasse der MVSK-MDB . . . . . . . . . . . . . . . . . . . .
A.8. Code-Beispiel eines Deployment-Deskriptors . . . . . . . . . . . . . . . . .
A.9. Code-Beispiel der Datei jboss.xml für die MVSK-MDB . . . . . . . . . .
A.10.Code des HomeRemote-Interfaces der MetadataRepository-EB . . . .
A.11.Code des Remote-Interfaces der MetadataRepository-EB . . . . . . .
A.12.Code der Bean-Klasse der MetadataRepository-EB . . . . . . . . . . .
A.13.Code-Beispiel eines Deployment-Deskriptors für eine EB . . . . . . . . . . .
A.14.Code-Beispiel der Datei jboss.xml für die MetadataRepository-EB
.
.
.
.
.
.
.
.
182
183
184
185
186
187
189
191
B.1. Code zum Zugriff auf eine Enterprise-Bean anhand ihres JNDI-Namens . . . . 194
C.1.
C.2.
C.3.
C.4.
C.5.
C.6.
Ausgaben des Testlaufes der einfachen Klassifikator-Induktion . . . .
Ausgaben des Testlaufes der inkrementellen Klassifikator-Induktion .
Ausgaben des Testlaufes eines Meta-Lern-Vorganges . . . . . . . . .
Ausgaben des Testlaufes einer naiven Klassifikator-Anwendung label
Ausgaben des Testlaufes einer Klassifikation mit Selection Graphs . .
Ausgaben des Testlaufes einer Klassifikator-Wartung . . . . . . . . .
224
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
195
197
199
201
204
206
Index
A
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Überblick . . . . . . . . . . . . . . . . . . . . . . . 26
Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 29
Agentenbasiert . . . . . . . . . . . . . . . . 29
Mediator-Wrapper . . . . . . . . . . . . . 31
Web-Service. . . . . . . . . . . . . . . . . . .32
Beispiele für Komponenten∼ . . . . . 27
Bewertungen . . . . . . . . . . . . . . . . . . . . 33
Agentenbasiert . . . . . . . . . . . . . . . . 33
Mediator-Wrapper . . . . . . . . . . . . . 34
Web-Service. . . . . . . . . . . . . . . . . . .35
Datenfluss-Modell . . . . . . . . . . . . . . . 26
Einführung . . . . . . . . . . . . . . . . . . . . . . 23
Enterprise JavaBeans . . . . . . . . . . . . . 38
Interface-Modell . . . . . . . . . . . . . . . . . 26
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . 28
Client-Server . . . . . . . . . . . . . . . . . . 28
Container . . . . . . . . . . . . . . . . . . . . . 28
Multi-Layer . . . . . . . . . . . . . . . . . . . 28
Prozess-Modell . . . . . . . . . . . . . . . . . . 26
Strukturmodell . . . . . . . . . . . . . . . . . . 25
Assoziationsanalyse . . . . . . . . . . . . . . . . . . 10
B
Basisklassifikator . . . . . . . . . . . . . . . . . . . . 19
C
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
D
Data Mining . . . . . . . . . . . . . . . . . . . . 2, 7, 10
Architektur . . . . . . . . . . . . . . . . . . . . . . 15
Distributed . . . . . . . . . . . . . . . . . . . . . . . 7
Data Warehouse . . . . . . . . . . . . . . . . . . . 4, 15
System . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Datenvorverarbeitung . . . . . . . . . . . . . . . . . . 8
DDM . . . . . . siehe Distributed Data Mining
Distributed Data Mining . . . . . . . . . . 2, 7, 16
Daten-Parallelisierung . . . . . . . . . . . . 18
Definition . . . . . . . . . . . . . . . . . . . . . . . 16
Task-Parallelisierung . . . . . . . . . . . . . 17
Distributed Knowledge Discovery . . . . . 16
E
EJB . . . . . . . . . . siehe Enterprise JavaBeans
EJB-Container
Datenbanken . . . . . . . . . . . . . . . . . . . . 40
Dienste . . . . . . . . . . . . . . . . . . . . . . . . . 39
Komponenten . . . . . . . . . . . . . . . . . . . 42
Messaging . . . . . . . . . . . . . . . . . . . . . . 40
Namens- und Verzeichnisdienst . . . 40
Persistence Manager . . . . . . . . . . . . . 42
Schnittstellen . . . . . . . . . . . . . . . . . . . . 39
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . 41
Transaktions-Monitor . . . . . . . . . . . . 40
Weitere Dienste . . . . . . . . . . . . . . . . . . 41
Enterprise JavaBeans . . . . . . . . . . . . . . 36, 37
Architektur . . . . . . . . . . . . . . . . . . . . . . 38
Begriffsklärungen . . . . . . . . . . . . . . . . 37
Container . . . . . . . siehe EJB-Container
Komponenten . . . . . . . . . . . . . . . . . . . 39
Enterprise-Bean
Implementierung . . . . . . . . . . . . . . . . . 43
Enterprise-Beans . . . . . . . . . . . . . . . . . . . . . 37
Aktivierung und Passivierung . . . . . 41
Bean-Typen . . . . . . . . . . . . . . . . . . . . . 42
Entity-Beans . . . . . . . . . . . . . . . . . . 43
Gegenüberstellung . . . . . . . . . . . . . 44
Message-Driven-Beans . . . . . . . . . 42
Session Beans . . . . . . . . . . . . . . . . . 42
Bestandteile . . . . . . . . . . . . . . . . . . . . . 43
Bestandteile EB . . . . . . . . . . . . . . . . 185
Bean-Klasse . . . . . . . . . . . . . . . . . . 187
Deployment-Deskriptor . . . . . . . 188
Home-Interface . . . . . . . . . . . . . . . 185
jboss.xml . . . . . . . . . . . . . . . . . . . . 191
Remote-Interface . . . . . . . . . . . . . 186
Bestandteile MDB . . . . . . . . . . . . . . 181
Bean-Klasse . . . . . . . . . . . . . . . . . . 181
jboss.xml . . . . . . . . . . . . . . . . . . . . 184
queue . . . . . . . . . . . . . . . . . . . . . . . . 181
Bestandteile SB . . . . . . . . . . . . . . . . . 177
Bean-Klasse . . . . . . . . . . . . . . . . . . 178
225
226
I NDEX
Home-Interface . . . . . . . . . . . . . . . 177
jboss.xml . . . . . . . . . . . . . . . . . . . . 180
Remote-Interface . . . . . . . . . . . . . 178
Installation . . . . . . . . . . . . . . . . . . . . . 193
Installation und Nutzung. . . . . . . . .193
Lebenszyklus . . . . . . . . . . . . . . . . . . . . 41
Nutzung . . . . . . . . . . . . . . . . . . . . . . . 194
Persistenz . . . . . . . . . . . . . . . . . . . . . . . 41
Verteilung . . . . . . . . . . . . . . . . . . . . . . . 41
Entscheidungsbaum . . . . . . . . . . . . . . . . 3, 11
Anwendung . . . . . . . . . . . . . . . . . . . . . 11
Entropie . . . . . . . . . . . . . . . . . . . . . . . . 14
ID3-Induktionsalgorithmus . . . . . . . 12
Induktion . . . . . . . . . . . . . . . . . . . . . . . 12
verteilte . . . . . . . . . . . . . . . . . . . . . . . 19
information gain . . . . . . . . . . . . . . . . . 14
Pruning . . . . . . . . . . . . . . . . . . . . . . . . . 15
Wurzel . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I
Individualsoftware . . . . . . . . . . . . . . . . . . . 26
Intelligenz . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
J
J2EE . . . . . . siehe Java 2 Enterprise Edition
Java 2 Enterprise Edition
Server . . . . . . . . . . . . . . . . . . . . . . . . . . 38
JavaBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
K
KDD . . . . . . siehe Knowledge Discovery in
Databases
Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . 11
Trainingsdaten . . . . . . . . . . . . . . . . . . . 11
Knowledge Discovery in Databases . . . 2, 7
M
MAS . . . . . . . . . . siehe Multiagentensystem
Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Meta-Lerner . . . . . . . . . . . . . . . . . . . . . . . 2, 20
Metadaten-Formate. . . . . . . . . . . . . . . . . . . 87
ADT-Interfaces und Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . 88
Kontrollflüsse . . . . . . . . . . . . . . . . . . 112
Parametrisierung der Algorithmen 131
Mobilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Multiagentensystem . . . . . . . . . . . . . . . . . . 30
Umwelt . . . . . . . . . . . . . . . . . . . . . . . . . 30
O
Objektorientiertes Design . . . . . . . . . . . . . 87
Komponenten . . . . . . . . . . . . . . . . . . 134
226
Metadaten-Formate . . . . . . . . . . . . siehe
Metadaten-Formate
Sequenz-Diagramme . . . . . . . . . . . . 140
Induktion . . . . . . . . . . . . . . . . . . . . 140
Meta-Lernen . . . . . . . . . . . . . . . . . 144
naive Klassifikation . . . . . . . . . . . 146
SG-Klassifikation . . . . . . . . . . . . . 149
Wartung . . . . . . . . . . . . . . . . . . . . . 152
Zusammenfassung . . . . . . . . . . . . . . 154
OOD . . . . . siehe Objektorientiertes Design
Operatoren
Anwendung . . . . . . . . . . . . . . . . . . . . . 58
Datenbank-Wrapper . . . . . . . . . . . . 60
Klassifikation . . . . . . . . . . . . . . . . . . 58
Selection-Graph-Ableitung . . . . . 59
Selection-Graph-Transformation 59
Selektion . . . . . . . . . . . . . . . . . . . . . . 58
Induktion . . . . . . . . . . . . . . . . . . . . . . . 56
Basisklassifikator-Selektion . 57, 59
Daten-Selektion . . . . . . . . . . . . . . . 56
Inkrementeller Lerner . . . . . . . 57, 61
Lerner . . . . . . . . . . . . . . . . . . . . . . . . 56
Meta-Lernen . . . . . . . . . . . . . . . . . . . . 57
Wartung . . . . . . . . . . . . . . . . . . . . . . . . 60
Daten-Selektion . . . . . . . . . . . . . . . 62
Invalidierung . . . . . . . . . . . . . . . . . . 61
Klassifikator-Selektion . . . . . . . . . 60
Lerner . . . . . . . . . . . . . . . . . . . . . . . . 61
Meta-Lerner . . . . . . . . . . . . . . . . . . . 60
R
ReDiCAt
Implementierung . . . . . . . . . . . . . . . 157
Referenz-System . . . . . . . . . . . . . 157
Tests . . . . . . . . . . . . . . . . . . . . . . . . 160
ReKlaMe . . . . . . . . . . . . . . . . . . . . . . . 2, 5, 47
Abläufe und Phasen . . . . . . . . . . . . . . 62
Induktion . . . . . . . . . . . . . . . . . . . . . 62
Klassifikation . . . . . . . . . . . . . . . . . . 66
Wartung . . . . . . . . . . . . . . . . . . . . . . 68
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . 48
Architektur . . . . . . . . . . . . . . . . . . . . . . 73
Überblick . . . . . . . . . . . . . . . . . . . . . 73
Anwendung . . . . . . . . . . . . . . . . . . . 79
Gesamt . . . . . . . . . . . . . . . . . . . . . . . 84
Induktion . . . . . . . . . . . . . . . . . . . . . 76
Verteiltheit . . . . . . . . . . . . . . . . . . . . 85
Wartung . . . . . . . . . . . . . . . . . . . . . . 82
Zusammenfassung . . . . . . . . . . . . . 86
Ausführungsmodell . . . . . . . . . . . . . . 47
Operatoren . . . . . . . . . siehe Operatoren
I NDEX
227
S
Simple Object Access Protocol . . . . . . . . 32
SOAPsiehe Simple Object Access Protocol
Software-Agent . . . . . . . . . . . . . . . . . . . . . . 30
Software-Architektur . . . . . . . . . . . . . . . . . 23
Software-Komponente . . . . . . . . . . . . . . . . 23
Standardsoftware . . . . . . . . . . . . . . . . . . . . .26
SWA . . . . . . . . . . . . . . siehe Software-Agent
T
Transformation . . . . . . . . . . . . . . . . . . . . . . . 9
W
Web Service Description Language . . . . 32
Web-Service . . . . . . . . . . . . . . . . . . . . . . . . . 32
Wissensbasis . . . . . . . . . . . . . . . . . . . . . . . . 10
Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
WSDL . . . . siehe Web Service Description
Language
227
228
I NDEX
228
Literaturverzeichnis
[BA96]
RONALD J. B RACHMANN und T EJ A NAND. The Process Of Knowledge Discovery in Databases. American Association for Artificial Intelligence, Menlo
Park, CA, USA, 1996. ISBN 0-262-56097-6
[Bär03]
S TEFAN B ÄRISCH. Gestaltung eines MAS zum Einsatz im VR-Learning, 2003
[BCK03]
L EN BASS, PAUL C LEMENTS und R ICK K AZMAN. Software Architecture in
Practice. Addison Wesley Professional, 2003. ISBN 0-321-15495-9
[BG01]
A NDREAS BAUER und H OLGER G ÜNZEL. Data Warehouse Systeme. Architektur, Entwicklung, Anwendung. Dpunkt Verlag, 2001. ISBN 3932588762
[Bre96]
L EO B REIMAN. Bagging Predictors. Machine Learning, 24(2):123–140,
1996. URL citeseer.ist.psu.edu/breiman96bagging.html,
letzter Zugriff 17.12.2004
[Böh01]
K LEMENS B ÖHM.
Kapitel 4: Data Preprocessing, 2001.
Aus: Vorlesung Data Warehousing und Data Mining, URL
http://www-dbs.inf.ethz.ch/˜boehm/DD/dwm0102/qualityaspekte.pdf,
[Com04]
The Common Component Architecture Forum: Glossary, 2004.
URL
http://www.cca-forum.org/glossary/index.html, letzter Zugriff 11.10.2004
[CRI04]
CRISP-DM
Process
Model,
2004.
http://www.crisp-dm.org/Process/index.htm,
griff 30.09.2004
letzter
URL
Zu-
[CS93]
P HILLIP K. C HAN und S ALVATORE J. S TOLFO.
Toward parallel and distributed learning by meta-learning.
In Working Notes
AAAI Work. Knowledge Discovery in Databases, Seiten 227–240. 1993.
URL citeseer.ist.psu.edu/chan93toward.html, letzter Zugriff
17.12.2004
[Dit97]
T.G. D ITTERICH. Machine Learning Research: Four Current Directions. In AI
Magazine 18(4), Seiten 97–136. 1997
[DP02]
S TEFAN D ENNINGER und I NGO P ETERS. Enterprise JavaBeans 2.0. AddisonWesley, 2002. ISBN 3-8273-1765-7. Zur Spezifikation 2.0
[ES00]
M ARTIN E STER und J ÖRG S ANDER. Knowledge discovery in databases: Techniken und Anwendungen. Springer, Berlin, 2000. ISBN 3-540-67328-8
[Fer01]
JAQUES F ERBER. Multiagentensysteme. Addison-Wesley, 2001. ISBN 3-82731679-0
229
230
L ITERATURVERZEICHNIS
[FPSS96a]
U SAMA M. FAYYAD, G REGORY P IATETSKY-S HAPIRO und PADHRAIC
S MYTH. The KDD Process for Extracting Useful Knowledge from Volumes
of Data. In Communications of the ACM 39(11), Seiten 27–34. 1996
[FPSS96b]
U SAMA M. FAYYAD, G REGORY P IATETSKY-S HAPIRO und PADHRAIC
S MYTH. Knowledge Discovery and Data Mining: Towards a Unifying Framework. In Knowledge Discovery and Data Mining, Seiten 82–88. 1996. URL
http://citeseer.nj.nec.com/fayyad96knowledge.html, letzter Zugriff 30.09.2004
[GGRL99]
J OHANNES G EHRKE, V ENKATESH G ANTI, R AGHU R AMAKRISHNAN und
W EI -Y IN L OH. BOAT — optimistic decision tree construction. In A LEX
D ELIS, C HRISTOS FALOUTSOS und S HAHRAM G HANDEHARIZADEH, Editoren, Proceedings of the 1999 ACM SIGMOD International Conference on
Management of Data: SIGMOD ’99, Philadelphia, PA, USA, June 1–3, 1999,
volume 28, Seiten 169–180. ACM Press, New York, NY 10036, USA, 1999.
URL http://citeseer.nj.nec.com/gehrke99boat.html, letzter
Zugriff 24.11.2004
[GHJV95]
E RICH G AMMA, R ICHARD H ELM, R ALPH J OHNSON und J OHN V LISSIDES.
Design Patterns. Addison-Wesley Professional, 1995. ISBN 0-2016-3361-2
[GS00]
Y I -K E G UO und JANJAO S UTIWARAPHUN. Distributed Classification with
Knowledge Probing, Kapitel 4, Seiten 115–132. In Kargupta und Chan [KC00],
2000
[HK00]
J IAWEI H AN und M ICHELINE K AMBER. Data Mining: Concepts and Techniques. Morgan Kaufmann, 2000. ISBN 1558604898
[HR03]
W ILHELM H ASSELBRING und R ALF R EUSSNER. Softwaresystementwicklung, 2003. Vorlesungsskript im Rahmen der Veranstaltung Softwaresystementwicklung an der Carl-von-Ossietzky Universität Oldenburg
[HSS+ 03]
JASON O. H ALLSTROM, N IGAMANTH S RIDHAR, PAOLO A.G. S IVILOTTI,
A NISH A RORA und W ILLIAM M. L EAL. A Container-Based Approach to
Object-Oriented Product Lines. Journal of Object Technology, 3(4):161–175,
2003
[HT01]
A RNE H ARREN und H EIKO TAPKEN. TODAY Open Repository. Technical Report TODAY-TR-2001-1, OFFIS, 2001. An Extensible MOF-Based Metadata
Repository System.
[HW01]
H AJO H IPPNER und K LAUS D. W ILDE. Handbuch Data Mining im Marketing
- Knowledge Discovery in Marketing Databases, Kapitel Der Prozess des Data
Mining im Marketing, Seiten 21–91. Vieweg Verlag, Wiesbaden, 2001
[JC99]
D. J ENSEN und P.R. C OHEN. Multiple Comparisons in Induction Algorithms,
Seiten 309–338. Kluwer Academic Publishers Hingham, MA, USA, 1999
[KB94]
W OLFGANG P. KOWALK und M ANFRED B URKE. Rechnernetze. Teubner
Verlag, 1994. ISBN 3519021412
[KBSvdW99] J. K NOBBE, H. B LOCKEEL, A. S IEBES und D. VAN DER WALLEN. MultiRelational Decision Tree Induction. In Proceedings of the 3rd European Conference on Principles and Practice of Knowledge Discovery in Databases, PKDD
99. 1999
230
231
[KC00]
H ILLOL K ARGUPTA und P HILIP C HAN, Editoren. Advances in Distributed
and Parallel Knowledge Discovery. AAAI/MIT Press, Menlo Park, CA / Cambridge, MA, 2000. ISBN 0-262-61155-4
[KKC00]
H ILLOL K ARGUPTA, C HANDRIKA K AMATH und P HILIP C HAN. Distributed
and Parallel Data Mining: Emergence, Growth, and Future Directions, Kapitel 15, Seiten 409–417. In Kargupta und Chan [KC00], 2000
[MEH01]
M ARK W. M AIER, DAVID E MERY und R ICH H ILLIARD. Software Architecture: Introducing IEEE Standard 1471. Computer, 34(4):107–109, 2001
[Meh03]
A XEL M EHNER. Eine agentenbasierte Softwareinfrastruktur zum verteilten Data Mining in Handhabungsdaten, 2003
[MH02]
R ICHARD M ONSON -H AEFEL. Enterprise JavaBeans. O’Reilly, 2002. ISBN
3897212978
[Mic04a]
Microsoft COM Technologies - Information and Resources for the
Component Object Model-based technologies, 2004.
Microsoft, URL
http://www.microsoft.com/com/, letzter Zugriff 19.10.2004
[Mic04b]
Microsoft
.NET
Information,
2004.
Microsoft,
http://www.microsoft.com/net/, letzter Zugriff 19.10.2004
[MST94]
D. M ICHIE, D. J. S PIEGELHALTER und C. C. TAYLOR, Editoren. Machine Learning, Neural and Statistical Classification. Ellis Horwood, New York,
1994. ISBN 013106360X
[Neb95]
W OLFGANG N EBEL. Entwurf Integrierter Schaltungen, Skriptum zur Vorlesung Entwurf Integrierter Schaltungen“, WS 1995/1996, 2. Auflage, Carl-von”
Ossietzky-Universität Oldenburg, 1995
[OMG02]
CORBA Component Model, v3.0, 2002. Object Management Group, URL
http://www.omg.org/technology/documents/formal/components.htm,
[PCS00]
A NDREAS L. P RODROMIS, P HILIP K. C HAN und S ALVATORE J. S TOLFO.
Meta-Learning in Distributed Data Mining Systems: Issues and Approaches,
Kapitel 3, Seiten 81–113. In Kargupta und Chan [KC00], 2000
[Pre03]
M ATTHIAS P RETZER.
Clustering und Klassifikation.
In Zwischenbericht Teil B der Projektgruppe Personalisierung internetbasierter Handelsszenarien, Seiten 125–162. 2003.
URL
http://diko-project.de/dokumente/ausarbeitungen/pretzer.pdf,
[Pre05]
M ATTHIAS P RETZER. Entwurf eines Ensemble-Lerners zum Kombinieren von
Entscheidungsbäumen unter Beachtung von Datenschutzaspekten. Diplomarbeit, Carl von Ossietzky Universität Oldenburg, 2005
[Pro00]
F OSTER P ROVOST. Distributed Data Mining: Scaling Up and Beyond, Kapitel 1, Seiten 3–27. In Kargupta und Chan [KC00], 2000
[Rob04]
O LIVER R EEMT ROBBE. Ein Werkzeug zur Administration eines agentenbasierten Softwaresystems, 2004
[Saa04]
C ARSTEN S AATHOFF.
Metadatengesteuerte Anwendung von Entscheidungsbäumen in Data Warehouse Systemen, 2004
231
URL
232
[SAS04]
SAS SEMMA, 2004. URL http://www.sas.com/technologies/analytics/data
[Sch90]
ROBERT E. S CHAPIRE.
The Strength of Weak
nability.
Machine Learning, 5:197–227, 1990.
citeseer.ist.psu.edu/schapire90strength.html,
Zugriff 17.12.2004
[Stu03]
R ALPH S TUBER.
Data Preprocessing - Datenvorverarbeitungsschritte
des Prozessmodelles.
In Zwischenbericht der Projektgruppe Personalisierung internetbasierter Handelsszenarien, Seiten 101–124. 2003. URL
http://diko-project.de/dokumente/ausarbeitungen/stuber.pdf,
[Sun97]
Java Beans API Specification, 1997. Sun Microsystems
[Sun04a]
Java 2 Platform, Enterprise Edition (J2EE), 2004. Sun Microsystems, URL
http://java.sun.com/j2ee/index.jsp, letzter Zugriff 14.10.2004
[Sun04b]
Enterprise JavaBeans Technology, 2004.
Sun Microsystems, URL
http://java.sun.com/products/ejb/index.jsp, letzter Zugriff
14.10.2004
[Sun04c]
Java 2 Platform, Standard Edition (J2SE), 2004. Sun Microsystems, URL
http://java.sun.com/j2se/index.jsp, letzter Zugriff 27.10.2004
[Sun04d]
Java Naming and Directory Interface (JNDI), 2004. Sun Microsystems, URL
http://java.sun.com/products/jndi/, letzter Zugriff 27.10.2004
[Sun04e]
Java Transaction API (JTA), 2004.
http://java.sun.com/products/jta/, letzter Zugriff 27.10.2004
[Sun04f]
JDBC
Technology,
2004.
Sun
Microsystems,
URL
http://java.sun.com/products/jdbc/, letzter Zugriff 27.10.2004
[Sun04g]
Java Message Service (JMS), 2004.
http://java.sun.com/products/jms/, letzter Zugriff 27.10.2004
[Sun04h]
JavaMail,
2004.
Sun
Microsystems,
http://java.sun.com/products/javamail/,
letzter
27.10.2004
[Sun04i]
Java API for XML Processing (JAXP), 2004. Sun Microsystems, URL
http://java.sun.com/xml/jaxp/, letzter Zugriff 27.10.2004
[Sun04j]
Java Remote Method Invocation (Java RMI), 2004. Sun Microsystems,
URL http://java.sun.com/products/jdk/rmi/, letzter Zugriff
27.10.2004
[Tal03]
D OMENICO TALIA. Parallel and Distributed Data Mining: from Multicomputers to Grids. In Proc. ECML/PKDD 2003 Workshop on Parallel and Distributed Computing for Machine Learning. 2003
[Tap04]
H EIKO TAPKEN. An Overview of the ReKlaMe-Approach. In British National
Conference on Databases, Edinburg, UK. 2004
232
LearURL
letzter
URL
Zugriff
233
[Tes03]
T HORSTEN T ESCHKE.
Semantische Komponentensuche auf Basis von
Geschäftsprozessmodellen. Diplomarbeit, Carl von Ossietzky Universität Oldenburg, 2003
[TG00]
K AGAN T URNER und J OYDEEP G HOSH. Robust Order Statistics-based Ensembles for Distributed Data Mining, Kapitel 6, Seiten 185–210. In Kargupta
und Chan [KC00], 2000
[W3C03]
SOAP Version 1.2 Part 1: Messaging Framework, 2003. W3C Recommendation, URL http://www.w3.org/TR/soap12-part1/, letzter Zugriff
19.10.2004
[W3C04]
Web Services Architecture, 2004.
W3C Working Group Note, URL
http://www.w3.org/TR/ws-arch/, letzter Zugriff 19.10.2004
[Zen03]
G UIDO Z ENDEL.
Der Prozess des Knowledge Discovery in Databases.
In Zwischenbericht der Projektgruppe Personalisierung
internetbasierter Handelsszenarien, Seiten 73–100. 2003.
URL
http://diko-project.de/dokumente/ausarbeitungen/zendel.pdf,
[Zen05]
G UIDO Z ENDEL. REBIND - Algorithmus für die Relationale Entscheidungsbauminduktion. Diplomarbeit, Carl von Ossietzky Universität Oldenburg, 2005
[Zho02]
Z HI -H UA Z HOU. Data Mining - Chapter 3 Data Preparation, 2002. Lehrveranstaltung Data Mining, 2002, Department of Computer Science and Technology,
Nanjing University, China
233
Hiermit versichere ich, daß ich diese Arbeit selbständig verfaßt und keine anderen als die angegebenen Hilfsmittel und Quellen verwendet habe.
Oldenburg, den 1. April 2005
(Ralph Stuber)

als PDF-Dokument - Informationssysteme

Transcription

Similar documents

Simple Features, AdaBoost und Kaskaden

La science évolue-t-elle ? Le point de vue des Big Data