Tool zur Softwarekomponentensuche

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme
Tool zur Softwarekomponentensuche
Bachelor-Arbeit
Georg Bader
betreut von
Dipl.-Ing. Dominic Pacher
Univ.Prof. Dr.rer.nat Günther Specht
Innsbruck, 9. November 2010
Zusammenfassung
Im Internet gibt es viele strukturähnliche Seiten mit interessanten Metainformationen. Informationen einer bestimmten Informationsquelle können mit Wrappern extrahiert werden. Diese lassen sich von automatischen Wrappergeneratoren auf Basis einer Trainingsphase generieren.
Ein Prototyp eines automatischen Wrappergenerators mit Spezialisierung auf die Extraktion von Opensourceprojekten auf Sourcecodeportalen wurde im Zuge dieser Arbeit implementiert. Hierbei wurde das
Webcrawlerframework namens Websphinx verwendet, um Webseiten zu
crawlen, sowie die Versionierungstools SVN, CVS und Git um Downloadunterstützung für die entsprechenden Repositories zu bieten.
Abstract
On the Internet there are many pages with interesting meta informations. Information from one single source can be extracted by Wrappers.
They can be generated by automatic Wrapper generators based on a phase of training. A prototype of an automatic Wrapper generator, which
is specialised on the extraction of open source projects found on source
code portals, has been implemented in the course of this work. To do so,
the webcrawler framework named Websphinx was used for crawling web
pages and the version control systems SVN, CVS and Git were used for
giving the possibility of downloading repositories.
Inhaltsverzeichnis
1 Einführung und Motivation
1.1 Sourcecodeportale . . . .
1.1.1 Sourceforge . . . .
1.1.2 Java.net . . . . . .
1.2 Aufbau Arbeit . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Related Work
2.1 Definition Informationsextraktion
2.2 Wrapper . . . . . . . . . . . . . .
2.3 Wrappergeneratoren . . . . . . .
2.4 Lixto . . . . . . . . . . . . . . . .
2.5 GATE . . . . . . . . . . . . . . .
3 Technologien
3.1 Webcrawler . . . . . . . . .
3.2 Websphinx . . . . . . . . .
3.2.1 Architektur . . . . .
3.2.2 Bugfixes . . . . . . .
3.2.3 Erweiterungen . . .
3.3 Versionsverwaltungssysteme
3.3.1 CVS . . . . . . . . .
3.3.2 SVN . . . . . . . . .
3.3.3 Git . . . . . . . . . .
3.4 Standard Widget Toolkit .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
.
.
.
.
.
5
5
5
5
6
7
.
.
.
.
.
.
.
.
.
.
9
9
10
10
12
13
14
14
15
15
16
4 Spezifikation
19
4.1 Use Case Digramm . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Fachliches Klassendiagramm . . . . . . . . . . . . . . . . . 21
4.3 Oberflächenprototyp . . . . . . . . . . . . . . . . . . . . . 22
5 Implementierung
23
5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Kontrollinstanz . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Grafische Benutzeroberfläche . . . . . . . . . . . . . . . . 27
III
INHALTSVERZEICHNIS
5.4
5.5
5.6
5.7
.
.
.
.
27
33
34
35
6 Handbuch
6.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Beispiel Sourceforge . . . . . . . . . . . . . . . . . . . . .
6.3 Beispiel java.net . . . . . . . . . . . . . . . . . . . . . . .
37
40
40
42
7 Schlusswort und Ausblick
45
Literaturverzeichnis
48
IV
Datenverarbeitung
WebCrawler . . . .
Download . . . . .
Zusammenfassung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Georg Bader
Kapitel 1
Einführung und Motivation
Oft bestehen Webseiten aus vielen Teilseiten mit gleicher Struktur. Diese zeichnen sich darin aus, dass sich an allen Seiten an gleichen Positionen genau die gleiche Art von Information befindet. Auch Sourcecodeportale wie zum Beispiel Sourceforge und Java.net verwenden strukturgleiche Teilseiten um Opensourceprojekte zu hosten. Im speziellen
Fall befindet sich auf verschiedenen Projektseiten eines Sourcecodeportals der Titel, der Autor, der Downloadlink, die Beschreibung und sonstige Metadaten des jeweiligen Projekts an der selben Stelle innerhalb
eines HTML-Dokuments. Diese Tatsache ermöglicht es, Programme zu
entwickeln, welche automatisiert gewünschte Informationen extrahieren
können. Wird dieser Ansatz um eine Instanz erweitert, welche diese Projektseiten aufspürt, so können automatisiert sämtliche Projekte eines
Portals erfasst werden. Durch einmalige Zuordnung von Semantik zu
den einzelnen Elementen ist es möglich, diese strukturiert zu speichern.
Wird ein solches Programm noch um die Möglichkeit des automatisierten Downloads von Repositories erweitert, so kann sämtlicher Quellcode aller Projekte eines Sourcecodeportals inklusive der zugehörigen
Metadaten automatisiert heruntergeladen werden. Im Zuge dieser Arbeit wurde ein Prototyp eines solches Programms entwickelt, welcher
es ermöglicht, Opensourceprojekte auf Sourcecodeportalen im Internet
ausfindig zu machen, dessen Metadaten zu erfassen sowie Unterstüzung
für das automatisierte Downloaden von Repositories bietet.
1.1
Sourcecodeportale
In diesem Kapitel sollen einige wichtige Vertreter jener Webseiten aufgezeigt werden, welche Opensourcesoftwareprojekte in strukturgleichen
Teilseiten präsentieren und somit dem Prototypen als Ziel dienen können.
1
KAPITEL 1. EINFÜHRUNG UND MOTIVATION
1.1.1
Sourceforge
Die Webseite Sourceforge1 ist ein Hoster für Opensourcesoftwareprojekte. Eigenen Angaben zu Folge ist sie die größte Entwicklungswebseite der
Welt mit 230.000 Software Projekten (Februar 2009) und über 2 Millionen registrierten Benutzern. Entwicklern wird damit eine Plattform
geboten, ihre Software-Repositories zu verwalten und zu veröffentlichen.
Betrieben wird die Webseite Sourceforge von der kalifornischen Firma
Geeknet, Inc. Die Seite kann mit dem Prototypen des Repositoryextraktionstools durchforstet werden. Dieser Vorgang wird beispielhaft in
Kapitel 6.2 beschrieben. Die Repositories verwenden die Versionierungstools CVS, SVN oder Git, welche durch den Prototypen unterstützt
werden. Die Seite hostet viele große Opensourcesoftwareprojekte wie:
• Gate [Soue]
• eMule [Soud]
• Azureus / Vuze [Soub]
• 7-Zip [Soua]
• BitTorrent [Souc]
1.1.2
Java.net
Ebenso wie das Portal Sourceforge stellt auch Java.net2 seinen Anwendern eine Umgebung zur Verfügung, um Software-Projekte auf deren
Servern weiter zu entwickeln und diese der Öffentlichkeit zugänglich zu
machen. Sämtliche Projekte beschäftigen sich mit den Java Technologien mit dem Ziel diese weiterzuentwickeln. Die Community besteht aus
industriellen Organisationen, Universitäten und individuellen Entwicklern. Der Prototyp des Repositoryextraktionstools wurde mit dem Portal
Java.net getestet und kann verwendet werden um Software-Projekte herunterzuladen. Eine Anleitung speziell zu Java.net findet sich in Kapitel
6.3. Einige bekannte Projekte, die auf Java.net gehostet werden, sind:
• glassfish [Java]
• jdk [Javb]
• jini [Javc]
1
2
2
http://sourceforge.net/
http://www.java.net/
Georg Bader
KAPITEL 1. EINFÜHRUNG UND MOTIVATION
1.2
Aufbau Arbeit
Die Arbeit ist wie folgt strukturiert. Im nachfolgenden Kapitel 2 wird
auf bereits vorhandene artverwandte Arbeiten eingegangen und die Terminologie erklärt. Des weiteren werden in Kapitel 3 die verwendeten
Technologien kurz beschrieben. Insbesondere wird auf das Webcrawlerframework namens WebSphinx eingegangen. Anschließend wird in Kapitel 4 eine Spezifikation des Programms gegeben. Kapitel 5 beschreibt die
Implementierung des Prototypen, welcher im Zug dieser Arbeit erstellt
wurde. Eingegangen wird auf die Architektur anhand von Diagrammen
und auf die Aufgabenbereiche der einzelnen Pakete und Klassen. Hinweise zur Installation des Prototypen sowie Hinweise zum erfolgreichen
Durchforsten beliebter Sourcecodeportale finden sich im Handbuch (Kapitel 6). Abschließend wird in Kapitel 7 eine Zusammenfassung mit anschließendem Ausblick gegeben.
Georg Bader
3
Kapitel 2
Related Work
2.1
Definition Informationsextraktion
Unter Informationsextraktion versteht man ein automatisiertes Verfahren zur Filterung von relevanten Informationen aus unstrukturierten
oder semistrukturierten Datenquellen (wie zum Beispiel HTML-Dokumenten), um strukturiertes Wissen daraus zu extrahieren [Voß06].
2.2
Wrapper
Ein Wrapper ist ein Programm, welches von einer bestimmten Datenquelle relevante Information extrahiert und diese in einer geeigneten
Form ausgibt [Eik99].
Die Extraktion erfolgt nach bestimmten Mustern. Zum Beispiel kann
ein Wrapper auf Basis von Präfixen und Suffixen definiert werden, um
den Bereich dazwischen zu extrahieren. Die Fertigkeiten von Wrappern
umfassen die Anfrage der Datenquelle (Herunterladen der Webseite),
die Extraktion der gewünschten Information und die Generierung von
Antwortobjekten für die Weiterverarbeitung durch andere Anwendungen [GRVB98]. Allerdings ist es hierzu notwendig, dass die URL einer
Datenquelle, welche die Antwort enthält, dem Wrapper übergeben wird.
Diese Aufgabe kann von einem anderen geeigneten Programm erledigt
werden, wie zum Beispiel von einem Crawler (Kapitel 3.1).
2.3
Wrappergeneratoren
Da ein Wrapper nur für eine bestimmte Informationsquelle verwendet
werden kann, und diese sich schnell ändern kann, besonders wenn es sich
dabei um eine Webseite handelt, besteht großer Bedarf an einer automatisierten Generierung von Wrappern. Diese Aufgabe übernehmen so
5
KAPITEL 2. RELATED WORK
genannte Wrappergeneratoren. Unterschieden wird zwischen drei verschiedenen Arten der Wrappererzeugung.
manuell Die Programmierung wird von Hand vorgenommen. Diese Methode ist sehr zeitaufwendig sowie fehleranfällig. Auf Grund der
raschen Weiterentwicklung von Webseiten besteht erhöhtes Risiko
für einen Funktionsausfall des Wrappers wegen statischer Regeln
im Quellcode. Es entstehen erhebliche Wartungskosten.
semi-automatisch Es kommen Wrappergeneratoren zum Einsatz. Diese ersparen dem Benutzer die Programmierarbeit, jedoch wird Expertenwissen zum jeweiligen Gebiet der Extraktion benötigt. Für
jede Datenquelle müssen separat Regeln definiert werden nach welchen Informationen gefiltert werden. Diese Methode ist weniger
fehleranfällig als das direkte Programmieren, jedoch abhängig von
Flexibilität und Funktionsumfang des Wrappergenerators.
automatisch Der Benutzer muss dem Wrappergenerator in einer Trainingsphase relevante Informationen deklarieren. Die Möglichkeiten
der Auswahl dieser Daten variieren mit der Qualität des Wrappergenerators. Diese reichen von einer Baumansicht der HTML-Seite,
in welcher einzelne Blätter ausgewählt werden können, bis zu einer komplett grafischen Präsentation der Datenquelle mit visueller
Markierungsunterstützung. Es kommen teilweise einfache bis hoch
komplexe Lernalgorithmen zum Einsatz um Informationen klassifizieren zu können [KT02].
2.4
Lixto
Ein Vertreter aus der Familie der Wrappergeneratoren ist Lixto. Es handelt sich hierbei um ein kommerzielles Tool, welches speziell Unternehmen, welche automatisiert und regelmäßig relevante Daten aus dem Internet kostensparend beziehen wollen, anspricht. Lixto ist ein voll visueller Wrappergenerator, das heißt der Benutzer muss sich nicht mit
HTML-Code oder Ähnlichem befassen, um einen Extraktionsvorgang
zu starten [BFG01].
Die Architektur wird in Abbildung 2.1 beschrieben. Der Interactive Pattern Builder stellt die grafische Oberfläche zur Verfügung. Dort kann der
Benutzer die gewünschten Extraktionsmuster und einen Basisalgorithmus für die Erstellung des eigentlichen Extraktionsprogramms, genannt
Elog Wrapper spezifizieren. Elog selbst ist eine deklarative Extraktionssprache, welche eine ähnliche Logik Syntax und Semantik hat wie
die Datenbankprogrammiersprache namens Datalog. Der Extractor ist
der Interpreter für das Elogprogramm, welches die eigentliche Extraktion durchführt. Dieser benötigt als Input das generierte Elogprogramm
6
Georg Bader
KAPITEL 2. RELATED WORK
Abbildung 2.1: Lixto Architektur [BFG01]
und eine HTML-Seite, auf welcher die Extraktion stattfinden soll. Als
Output wird eine pattern instance base, eine Datenstruktur, welche die
extrahierten Informationen hierarchisch geordnet enthält, generiert. Der
XML-Generator bietet dem Benutzer die Möglichkeit zu bestimmen, wie
die gefilterten Informationen zugeordnet werden sollen. Auf Basis dieses
Mappings wird als Ausgabe eine XML-Datei erstellt.
2.5
GATE
Die Programmfamilie mit dem Titel General Architecture for Text
Engineering, kurz GATE, ermöglicht die Verarbeitung natürlicher Sprache inklusive Informationsextraktion für viele Sprachen [BTMC04]. Die
Entwicklung begann 1995 durch die Universität von Sheffield. Heute
wird GATE von einer weltweiten Community bestehend aus Wissenschaftlern, Unternehmen, Lehrenden und Studenten betreut. Der Kern
von GATE wird im Rahmen eines Opensourceprojekts entwickelt und
ist auf Sourceforge verfügbar. Die gesamte GATE-Familie besteht aus
den folgenden Programmen.
GATE Developer: eine integrierte Entwicklungsumgebung zum Erstellen und Bearbeiten von Softwarekomponenten, mit welchen die
Verarbeitung von menschlicher Sprache kontrolliert wird
GATE Embedded: eine Objektbibliothek optimiert für die Einbettung der Funktionalität von GATE Developer in eigene Applikationen
Georg Bader
7
KAPITEL 2. RELATED WORK
GATE Teamware: eine Webapplikation zum gemeinschaftlichen Erstellen von Textanmerkungen
GATE Cloud: eine parallele und verteilte Verarbeitungseinheit, welche GATE Embedded mit einer stark optimierten Serviceinfrastruktur verbindet
8
Georg Bader
Kapitel 3
Technologien
3.1
Webcrawler
Diese Programme sind auch bekannt unter den Begriffen Spider oder
Searchbot. Es handelt sich hierbei um Anwendungen, welche das World
Wide Web Seite um Seite durchforsten. Eingesetzt werden diese etwa
von Suchmaschinen, um besuchte Seiten einer Indizierung zu unterziehen. Die Arbeitsweise eines Webcrawlers lässt sich in folgende Schritte
einteilen [Cot04]:
1. Ein Link wird aus einer Liste ausgewählt.
2. Wenn dieser noch nicht besucht wurde, dann wird das Ziel heruntergeladen.
3. Handelt es sich dabei um eine HTML-Seite, werden alle weiterführenden Links der Liste hinzugefügt.
4. Wiederholen der Schritte 1 bis 3 bis keine unbesuchten Links mehr
in der Liste vorhanden sind.
Abbildung 3.1: WebCrawler Architektur [Cot04]
9
KAPITEL 3. TECHNOLOGIEN
Die Basis Architektur eines Crawlers wird in Abbildung 3.1 illustriert.
Der Fetcher lädt Dateien aus dem World Wide Web herunter. Welche Seite geladen werden soll, kontrolliert der Controller mittels Weiterleitung eines Links aus dem Workload. Eine geladene Seite wird an
den Link extractor überreicht, welcher Hyperlinks aufspürt und diese
dem Workload hinzufügt. Somit ist gewährleistet, dass in den folgenden
Schritten die Seiten, welche die Ziele der Links darstellen ebenfalls gecrawlt werden. Anschließend wird die Seite dem Summarizer übergeben,
um diese je nach Aufgabe des Crawlers zu verarbeiten. Die erhaltenen
Ergebnisse werden entsprechend im Information store gespeichert.
Die Unterscheidung, ob es sich bei einem Crawler um einen einfachen
oder fortgeschrittenen handelt, ist abhängig von der Leistungsfähigkeit
des Link extractors. Beherrscht dieser lediglich die Extraktion von Links
aus HTML-Seiten, spricht man von einem einfachen Crawler. Kann dieser jedoch auch aus Dateien mit anderen Formaten wie txt, doc, zip,
oder pdf Links erkennen, handelt es sich um einen fortgeschrittenem
Crawler [NH02, CGM02].
3.2
Websphinx
WebSphinx (Website-Specific Processors for HTML INformation eXtraction) ist ein Webcrawlerframework für die Entwicklung von Javaprogrammen. Es verfügt über eine grafische Oberfläche, genannt crawler workbench, welche die Personalisierung, Ausführung und Visualisierung von Crawlern unterstützt. Einfache Crawler lassen sich damit ohne
Programmierarbeit in kurzer Zeit spezifizieren und ausführen. Das Framework dient dem Prototypen, welcher im Zuge dieser Arbeit erstellt
wurde, als Basis eines Crawlers. Im nächsten Kapitel wird auf die Architektur von WebSphinx sowie auf die zahlreichen Erweiterungen und
Bugfixes eingegangen.
3.2.1
Architektur
WebSphinx betrachtet das Internet als einen gerichteten Grafen bestehend aus Seiten und Links. Diese werden in den Objekten Page und
Link abgebildet. Ein Page-Objekt repräsentiert eine geparste Webseite und verfügt über Methoden, um zum Beispiel die URL, den Titel,
oder den Parsetree der Seite zurückzugeben. Des weiteren findet sich
unter den Attributen eine Sammlung von Link-Objekten, welche auf
dieser Seite als weiterführende Hyperlinks entdeckt wurden. Ein LinkObjekt beschreibt nicht nur das Ziel, eine URL, sondern auch ein HTMLElement auf der Seite, auf welcher es gefunden wurde. Der Parsetree
einer Seite setzt sich aus einer Vielzahl von HTML-Elementen zusammen, welche in Element-Objekten abgebildet werden. Elemente bestehen
10
Georg Bader
KAPITEL 3. TECHNOLOGIEN
Abbildung 3.2: Vererbung Region
aus je einem Start- und Endtag. Diese wiederum werden mit Hilfe von
Tag-Objekten realisiert. Ein HTML-Dokument wird abgebildet in einem Page-Objekt. Dieses enthält eine Referenz auf das Root-Element
des Parsetrees. Der Parsetree beseht aus einem Baum von ElementObjekten. Jedes Element verfügt über eine Referenz auf seinen Vorfahren im Baum (parent), seinem ersten Nachfahren (child), sowie zu
seinem ersten Geschwisterknoten (sibling). Abbildung 3.3 zeigt die Assoziationen zwischen den Klassen Page, Element, Tag und Text. Alle
diese Klassen erben von der Klasse Region. Die Klasse Link ist eine
Spezialisierung der Klasse Element. Die Vererbungsstruktur wird verdeutlicht durch Abbildung 3.2. Die Klasse Region implementiert eine gemeinsame Basis aller Bestandteile einer Webseite. Jede Region
verfügt über zwei Integer-Variablen, welche die Start- und Endposition innerhalb des Quelltextes seines zugehörigen Page-Objektes anzeigt. Weiters werden Methoden zur Verfügung gestellt, wie zum Beispiel
toText():String. Diese Methode ruft auf das zugehörige Page-Objekt
die Funktion substringText(start, end):String auf. Ein Page-Objekt verfügt über eine Sammlung aller auf der Seite vorkommenden
Bestandteile, also Objekte der Klassen Element, Link, Tag, Text und
Region. Die Klasse Text wird als Container für einzelne Wörter (keine
Tags), separiert durch Leerzeichen, verwendet. Die Methode substring
Text(start, end):String returniert einen String bestehend aus den
Text-Objekten, welche sich innerhalb der Grenzen start und end befinden.
Um auf den Parsetree der Seiten zugreifen zu können, müssen diese zuerst heruntergeladen werden. Diesen Vorgang steuert die Klasse Crawler.
Ein Crawler-Objekt verfügt über mehrere Threads, welche sich um
das Herunterladen der Webseiten kümmern. Diese entnehmen LinkObjekte aus einer Prioritäten-Warteschlange und generieren aus dem
empfangenen Quelltext mit Hilfe der Klasse HTMLParser Page-Objekte. Die entstandenen Page-Objekte werden nacheinander den Methoden classify(Page) eines jeden registrierten Classifiers übergeben.
Georg Bader
11
KAPITEL 3. TECHNOLOGIEN
Abbildung 3.3: Page, Element, Tag, Text Assoziation
Diese versehen die auf den Seiten enthaltenen Links mit Markierungen. Auf Basis dieser Markierungen werden die Links in die PrioritätenWarteschlange eingeordnet oder verworfen. Der Crawlvorgang wird beendet, sobald die Warteschlange abgearbeitet wurde oder durch eine
entsprechende Interaktion des Benutzers.
Für den Prototypen des Repositoryextraktionsprogramms stellt der Crawlvorgang das Kernstück der Suche dar. Umso wichtiger ist es daher, sich
auf das korrekte Arbeiten des Crawlers verlassen zu können. Leider war
dies auf Grund der raschen Weiterentwicklung des World Wide Webs
und des beträchtlichen Alters der WebSphinx-Routinen nicht ohne programmiertechnische Erweiterungen möglich.
3.2.2
Bugfixes
In diesem Kapitel werden einige der benötigten Bugfixes und Erweiterungen der Routinen von WebSphinx aufgezeigt. Auf Grund der verschiedenen Methoden der Anfrage beziehungsweise des Parsens einer
Webseite durch den SWT-Browser und den Webcrawler entstehen zwei
verschiedene Page-Objekte. Für die weitere Behandlung müssen diese jedoch auf eine gemeinsame Basis gebracht werden. Hierfür wurde
ein Verfahren entwickelt, welches die Textbausteine einer Webseite vergleicht und für diese ein Mapping findet, welches jedem Text-Element
des einen Page-Objektes ein Text-Element des anderen Page-Objektes
zuordnet. Für die Umsetzung dieses Algorithmus werden die Methoden
toText():String aller Objekte des Parsetrees benötigt. Probleme traten hierbei bei Link-Objekten auf, da diese die Implementierung der
Methode toText():String der Klasse Region überschreiben, um ausschließlich den Anchortext des Links zurückzugeben.
Bei der Methode toTags():String ist den Entwicklern von WebSphinx
folgender Fehler unterlaufen:
public String toTags () {
return source.substringText (start, end);
12
Georg Bader
KAPITEL 3. TECHNOLOGIEN
}
Dies hat zur Folge, dass anstatt des erwarteten Strings, bestehend aus
Tags, ein String bestehend aus Tag-freiem Text zurückgegeben wird.
Richtig ist diese Version:
public String toTags () {
return source.substringTags(start, end);
}
3.2.3
Erweiterungen
In diesem Kapitel sollen kurz kleinere und größere, jedoch notwendige,
Erweiterungen beschrieben werden, welche es verhindern sollen, dass das
Extraktionsprogramm mit gleichen oder nutzlosen Webseiten überlastet
wird und um sinnvolle Links aus dem Crawlvorgang nicht auszuschließen.
IP-Vergleich
Der Crawlvorgang wurde um Zeit zu sparen auf Links, welche auf Webseiten desselben Webservers verweisen, eingeschränkt. Die Überprüfung
dieser Bedingung basiert im originalen WebSphinx auf URL-Vergleich.
Zum Beispiel findet sich unter https://www.dev.java.net/servlets/
ProjectList eine Liste aller Projekte auf Java.net. Die Details zu einem einzelnen Projekt allerdings haben einen anderen Aufbau der URL.
Diese lautet zum Beispiel für das Projekt cnmonitoring auf https://
cnmonitoring.dev.java.net/. Die Ursprüngliche Implementierung erkennt hier nicht, dass beide Seiten zur selben Webseite gehören. Die
Folge daraus ist, dass dieser Link nicht gecrawlt werden wird. Um dieses Problem zu beheben wurde eine Variante implementiert, welche die
IP-Adressen der Seiten vergleicht, um sicher gehen zu können keine Teilseiten einer Webseite ungewollt auszuschließen.
Session-ID
Manche Webseiten verwenden um mehrere Anfragen eines Benutzers
einer Sitzung zuordnen zu können in den URLs eigene Session-IDs. Diese Einführung ist eine Möglichkeit im an sich zustandslosen Protokoll
HTTP einen Zustand zu codieren. Adressen mit angehängten SessionIDs können bei der Überprüfung, ob eine Seite schon gecrawlt wurde,
zu Problemen führen. Daher erfolgt die Überprüfung auf Basis der URL
ohne die Session-ID.
Georg Bader
13
KAPITEL 3. TECHNOLOGIEN
https
Bei der originalen Klassifizierung durch die Klasse StandardClassifier
von gefundenen Links werden diese eingeteilt in die Kategorien resource,
form oder hyperlink. Die Implementierung des Prototypen folgt ausschließlich Links der Kategorie hyperlink. Links werden als Hyperlinks
klassifiziert auf Basis der einleitenden HTML-Tags, der verwendeten Anfrage Methode und dem verwendetem Protokoll. Die Menge der gültigen
Protokolle wurde ergänzt um https, da zum Beispiel Projekte auf java.net ausschließlich über dieses Protokoll erreichbar sind.
Zeichencodierung
Diese Erweiterung war nötig, um bei der Darstellung von gecrawlten
Webseiten auf unerwartete Zeichen im Text verzichten zu können. Das
Problem tritt zum Beispiel auf, wenn eine Webseite mit Umlauten im
Text, codiert mit ISO 8859-1 dargestellt wird als UTF-8 Dokument.
Der Grund hierfür liegt darin, dass zum Beispiel das Zeichen ä mit
ISO 8859-1 codiert dem hexadezimalen String 0xE4 entspricht und mit
UTF-8 codiert dem hexadezimalen String 0xC3 0xA4. Um dieses Problem
zu lösen, wurde der verwendete Zeichensatz bereits beim Herunterladen
der Webseite ausgelesen, um anschließend die erhaltenen Bytes dementsprechend decodieren zu können.
3.3
Versionsverwaltungssysteme
Ein Repository (engl. für Lager, Depot), auch Repositorium, ist ein verwaltetes Verzeichnis zur Speicherung und Beschreibung von digitalen
Objekten sowie deren Metadaten [Wik10]. Bei den verwalteten Objekten
handelt es sich in diesem Kontext um Quellcode von freien Programmen
also Softwarerepositories. Diese werden mittels Versionierungs-Tools wie
CVS, SVN oder Git verwaltet (Versionsverwaltungssysteme). Mit Hilfe
dieser Programme können Softwareentwickler komfortabel Quellcodedateien verwalten. Bekannte Sourcecodeportale, wie Sourceforge und Java.net setzen auf diese Technologien. In den nächsten Kapiteln werden
die einzelnen durch den Prototypen unterstützten Versionierungs-Tools
beleuchtet.
3.3.1
CVS
Das Concurrent Versions System oder kurz CVS ist ein zentralisiertes Versionsverwaltungssystem. Das heißt, die Quellcodedateien werden
in einem Repository oder Programmarchiv gehalten. Das Herunterladen von Dateien wird auschecken“ genannt. Dieses System ermöglicht
”
14
Georg Bader
KAPITEL 3. TECHNOLOGIEN
mehreren Benutzern gleichzeitig an einem Projekt zu arbeiten. CVS
ermöglicht die Aufzeichnung der Geschichte der einzelnen Dateien. Dies
ist sehr nützlich, falls auf Grund einer fehlerhaften Programmierung die
Datei zu einem früheren Zeitpunkt wiederhergestellt werden soll. Wurde eine Quelldatei verändert, kann diese in das Repository eingecheckt“
”
werden. Das gleichzeitige Arbeiten von verschiedenen Entwicklern an der
selben Datei kann zu Problemen führen. Diese können entweder durch
den merge“-Befehl oder durch manuelles Anpassen der Datei [Gru86]
”
gelöst werden. Um den Prototypen mit CVS-Unterstützung verwenden
zu können, ist es nötig, ein CVS-Programm zu installieren, welches sich
über den Kommandozeilenaufruf cvs starten lässt.
3.3.2
SVN
Subversion oder kurz SVN ist ebenso wie CVS ein zentralisiertes Versionsverwaltungssystem. Entwickelt wurde es von CollabNet, welche es als
freie Software unter der Apache-Lizenz veröffentlichten. SVN wird allgemein als die Weiterentwicklung von CVS verstanden. Entstanden ist es
durch die weit verbreitete Kritik an CVS. Bei der Entwicklung wurden
einfache Ziele definiert, welche ein verbessertes Versionierungs-Tool mit
dem selben Funktionsumfang wie CVS zum Ergebnis haben sollte, jedoch ohne dessen offensichtlichen Fehlern. Eine wesentliche Verbesserung
stellt zum Beispiel die Möglichkeit des Verschiebens und Umbenennens
von Dateien und Verzeichnissen dar, ohne dabei die Versionsgeschichte
zu verlieren. Die Bedienung von SVN entspricht im Großen und Ganzen derer von CVS. Nicht zuletzt um Benutzern von CVS den Umstieg
zu erleichtern [PCSF08]. Um den Prototypen mit SVN-Unterstützung
verwenden zu können, ist es nötig, ein SVN-Programm zu installieren,
welches sich über den Kommandozeilenaufruf svn starten lässt.
3.3.3
Git
Git ist im Gegensatz zu CVS und SVN ein verteiltes Versionsverwaltungssystem. Es wurde ursprünglich von Linus Torvalds zur Verwaltung des Linux-Kernel-Quellcodes entwickelt. Wichtiges Merkmal von
Git ist, dass kein zentraler Server benötigt wird. Jeder Benutzer besitzt eine lokale Kopie des gesamten Repositories inklusive der Versionsgeschichte. Für die meisten Arbeiten ist daher keine Verbindung zum
Internet nötig. Sollen die lokalen Änderungen in das offizielle Repository übertragen werden, muss eine Verbindung dorthin bestehen. Die
Übertragung erfolgt über ein eigenes Protokoll, welches den Port 9418
verwendet. Andere Protokolle werden ebenfalls unterstützt wie zum Beispiel ssh, http oder ftp. Um den Prototypen mit Git-Unterstützung verwenden zu können, ist es nötig ein Git-Programm zu installieren, welches
Georg Bader
15
KAPITEL 3. TECHNOLOGIEN
Abbildung 3.4: SWT: Look and Feel
sich über den Kommandozeilenaufruf git starten lässt.
3.4
Standard Widget Toolkit
Das Standard Widget Toolkit, kurz SWT, ist ein Framework zur Gestaltung von GUIs1 für die Programmiersprache Java. Das Toolkit wurde
2001 von IBM für die Oberflächengestaltung der bekannten Entwicklungsumgebung Eclipse entwickelt. Neben SWT gibt es noch zwei andere bekannte Toolkits zur Java Oberflächenprogrammierung, nämlich
AWT2 und Swing. SWT setzt, sowie AWT, auf die Verwendung von nativen Grafikelementen des jeweiligen Betriebssystems. Dies zeigt sich bei
einem Vergleich der Optik von SWT- und Betriebssystemoberflächen.
Somit entsprechen SWT-Applikationen, wie Abbildung 3.4 illustriert,
einem nativen Look and Feel.
Dem Programmierer wird zur Einbindung von SWT-Widgets eine Java API3 zur Verfügung gestellt. Intern verwendet SWT JNI-Aufrufe4 ,
um Funktionalität aus nativen Systembibliotheken zu nutzen. Java Programme verlieren durch Plattformen, auf welchen die nötigen Programmbibliotheken nicht verfügbar sind, den Vorteil gänzlich plattformunabhängig zu sein. Allerdings werden die wichtigsten Betriebssysteme wie
Windows, Linux, Mac OS X und Solaris unterstützt.
SWT besteht aus einer Vielzahl von Grafikelementen genannt Widgets,
welche sich in GUIs einbinden lassen. Mit den folgenden Codezeilen wird
ein Knopf mit dem Text Hallo Welt!“ eingebettet.
”
Button t e s t B t n = new Button ( parentComposite , SWT. PUSH) ;
t e s t B t n . s e t T e x t ( " Hallo Welt ! " ) ;
SWT ist so aufgebaut, dass jedes Widget genau ein Vaterelement benötigt,
in welchem es dargestellt werden soll. In diesem Fall wird der Knopf
dem Widget parentComposite zugeteilt. Neben den eher einfacheren
1
Graphical User Interface.
Abstract Window Toolkit.
3
Application Programming Interface.
4
Java Native Interface.
2
16
Georg Bader
KAPITEL 3. TECHNOLOGIEN
Elementen wie Knöpfen, Texten, Listen, Bäumen, usw. gibt es noch anspruchsvollere wie zum Beispiel Dialoge oder aber das Browser-Widget.
Dieses funktioniert wie alle anderen Elemente auch über die Einbindung von nativer Funktionalität, im speziellen Fall die Einbindung von
HTML-Renderingengines zur visuellen Repräsentation von HTML. Bei
Windows etwa wird auf den Internet Explorer zurückgegriffen. Unter
Linux findet die Renderingengine gecko von Mozilla Verwendung. Der
Vorteil liegt darin, dass diese Browser-erprobten Engines Webseiten mit
sehr guter Qualität rendern. Des weiteren haben diese auch keine Probleme mit CSS5 oder JavaScript, welche sich immer größerer Beliebtheit
erfreuen.
Die Möglichkeit der einfachen und guten Darstellung von Browserfenstern in einer Java GUI war das Schlüsselkriterium für die Auswahl von
SWT als Oberflächenprogrammierungsframework [NW04].
5
Cascading Style Sheets
Georg Bader
17
Kapitel 4
Spezifikation
Im Zuge dieser Arbeit wurde ein Prototyp eines Informationsextraktionsprogramms entwickelt. Der Prototyp soll folgende Funktionalität zur
Verfügung stellen:
• Suche von Opensourceprojekten,
• Erfassung von Metadaten,
• Downloadunterstützung für Repositories,
• Speicherung gewonnener Daten und
• Automatisierung genannter Schritte.
Um die aufgeführte Funktionalität bereitstellen zu können, werden mehrere verschiedene Technologien in die Entwicklung des Prototypen miteinbezogen. Für die Gestaltung einer grafischen Oberfläche wird das
Oberflächenprogrammierframework SWT (Kapitel 3.4) verwendet, um
Browserfenster einfach einbetten zu können. Die Realisierung der automatisierten Suche basiert auf dem Webcrawlerframework namens WebSphinx (Kapitel 3.2). Die Downloadunterstützung für Repositories wird
erreicht durch die Miteinbeziehung der Versionierungstools (Kapitel 3.3)
SVN, CVS und Git. Die Implementierung des Prototypen erfolgte mittels der Programmiersprache Java. Details der Implementierung, wie die
einzelnen verwendeten Komponenten, werden im Kapitel 5 erläutert. In
den nächsten Unterkapiteln werden Anwendungsfälle identifiziert, ein
grober Überblick über die benötigten Komponenten gegeben sowie der
Prototyp der grafischen Oberfläche präsentiert.
19
KAPITEL 4. SPEZIFIKATION
4.1
Use Case Digramm
In diesem Unterkapitel werden die wichtigsten Interaktionen des Benutzers mit dem System identifiziert. Diese werden in einem Use Case
Diagramm (Abbildung 4.1) vereinfacht dargestellt. Zunächst kann der
Benutzer durch die Angabe einer URL eine Webseite anzeigen lassen.
Auf den angezeigten Webseiten können Zielelemente markiert werden.
Diese können als Bedingung für die automatisierte Suche festgelegt werden. Neue Bedingungen lassen sich hinzufügen sowie bereits vorhandene
löschen. Der HTML-Pfad von Elementen kann bearbeitet werden. Elemente können einzeln dargestellt werden, um eine Auswahl überprüfen
zu können. Ist der Benutzer mit den getroffenen Bedingungen zufrieden, kann der Suchvorgang gestartet werden. Die Suche lässt sich durch
die Anzeige des Suchgraphen visualisieren. Nach Beendigung der Suche durch den Benutzer können die Ergebnisse gespeichert werden. Der
Download gefundener Repositories kann gestartet werden.
Abbildung 4.1: Use Case Diagramm
20
Georg Bader
KAPITEL 4. SPEZIFIKATION
4.2
Fachliches Klassendiagramm
Um die identifizierten Anwendungsfälle aus Kapitel 4.1 verwirklichen zu
können, wird eine Struktur benötigt, welche die gewünschte Funktionalität zur Verfügung stellt. Die geplante Architektur wird in Abbildung
4.2 dargestellt. Eine Klasse Controller soll die Komponeten Gui, Crawler, Extraktion und Data kontrollieren und für entsprechenden Datenaustausch sorgen. Die Suche von Webseiten soll durch eine Klasse Crawler realisiert werden. Webseiten sollen in einem Browserfenster, einem
Teilbereich der Gui, dargestellt werden. Webseiten sollen aus mehreren
Elementen bestehen. Bestimmte Elemente können durch die Klasse Extraktion selektiert und mit Hilfe der Klasse Data zwischengespeichert
werden.
Abbildung 4.2: Fachliches Klassendiagramm
Georg Bader
21
KAPITEL 4. SPEZIFIKATION
4.3
Oberflächenprototyp
Um dem Benutzer eine komfortable Bedienung ermöglichen zu können,
wurde eine grafische Bedienungsoberfläche entwickelt. Diese besteht aus
verschiedenen Teilbereichen, wie in Abbildung 4.3 zu sehen ist. Der
größte Bereich besteht aus einem Browserfenster für Navigation zwischen Webseiten und der Darstellung auch von einzelnen HTML-Elementen. Die Reiter Input, Output und Download wurden so gewählt,
dass je nach Arbeitsfortschritt von einem in den nächsten gewechselt
werden kann. Die Steuerung des Crawlers wird im linken oberen Teil
der Oberfläche ermöglicht.
Abbildung 4.3: Oberflächenprototyp
22
Georg Bader
Kapitel 5
Implementierung
In diesem Kapitel wird die Implementierung des Informationsextraktionsprogramms beschrieben, welches im Zuge dieser Arbeit entwickelt
wurde. Der Prototyp verwirklicht die Arbeitsschritte, welche in Abbildung 5.1 grob zusammengefasst zu sehen sind.
Abbildung 5.1: Arbeitsschritte Prototyp
1. Der Benutzer ruft im SWT-Browser einen beliebigen Vertreter der
strukturgleichen Webseite seiner Wahl auf.
23
KAPITEL 5. IMPLEMENTIERUNG
2. Das gewünschte Element wird auf der angezeigten Seite markiert.
3. Der HTML-Pfad des markierten Elements wird ausgelesen.
4. Sobald der Suchvorgang gestartet wird, beginnt der Crawler auf
Basis der aktuellen Seite andere Seiten mit der selben Struktur zu
suchen.
5. Gefundene Seiten werden dem PathClassifier übergeben.
6. Der PathClassifier überprüft die gecrawlte Seite auf ein Vorkommen des Zielelements durch einen Vergleich der HTML-Pfade.
7. Wird ein Element mit identischem Pfad gefunden, wird es als Treffer gespeichert.
Um die gesamte Funktionalität des Prototypen zu erzielen, werden zahlreiche Pakete und Klassen benötigt. In den nächsten Abschnitten werden
diese dem Leser näher erklärt.
5.1
Architektur
Abbildung 5.2: Übersicht Pakete
Der Prototyp des Repositoryextraktionsprogrammes, welcher im Zuge
dieser Arbeit entwickelt wurde, besteht aus zwei Java Projekten. Das
Webcrawlerframework namens WebSphinx bildet zusammen mit etlichen Erweiterungen und Bugfixes das Basis-Projekt, siehe Kapitel 3.2.
Auf diesem Projekt aufbauend wurde das eigentliche Extraktionsprojekt
entwickelt. Dieses stellt zusammengefasst die Funktionalität für das visuelle Markieren des Pfades im Browser, die Klassifizierung gefundener
Seiten und die Download-Steuerung zur Verfügung. Das Projekt besteht
aus den Paketen:
24
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
• controller
• crawler
• data
• download
• gui
Das Zusammenspiel der einzelnen Pakete wird in Abbildung 5.2 veranschaulicht. Die Beziehungen der einzelnen Pakete zueinander wird
durch Pfeile beschrieben. Die Schlagwörter Call bzw. Access bzw. Instantiate bzw. Import stehen für eine Aufruf- bzw. Zugriffs- bzw.
Erzeugungs- bzw. Importbeziehung. Die Pakete werden in je einem
Kapitel genauer erläutert.
5.2
Kontrollinstanz
Das Paket controller, Abbildung 5.3, stellt das zentrale Element des
Repositoryextraktionsprogramms dar. Es übernimmt die Dialogkontrolle, die Ablaufsteuerung und die Verbindung zu den anderen Paketen,
siehe Abbildung 5.2. Die wichtigste Klasse darin stellt die Klasse Controller dar. Die main Methode zum Starten des Programms befindet
sich in dieser Klasse. Beim Start wird ein Gui Objekt erzeugt, welches als Ansprechpartner für Methodenaufrufe eine Referenz auf den
Controller erhält. Die public Methoden werden von der Klasse Gui angesprochen und stoßen damit einen Geschäftsprozess entsprechend dem
MVC1 Architekturmuster an. Der Controller im MVC-Muster entspricht
der Klasse Controller, die View der Klasse Gui und das Model dem WebCrawler, wessen Daten durch das Paket data abgebildet werden. Die
Klasse Controller implementiert die Interfaces LinkViewListener, LinkListener, CrawlListener und Observer, um auf Ereignisse des Crawlers,
der Crawler-Visualisierung beziehungsweise dem Datenmodell reagieren
zu können.
Die Klasse BrowserHelper kümmert sich um das Auslesen des HTMLPfades eines markierten Elements im Browserfenster und um das Angeleichen der HTML-Seiten des SWT-Browsers an den Webcrawler. Dies
ist nötig, da der Browser und der Crawler jeweils eine eigene Anfrage und Download Routine, sowie einen eigenen HTML-Parser implementiert haben, welche den Quellcode von HTML-Seiten nicht identisch
wiedergeben. Um dieses Problem zu lösen, wurde ein Verfahren, basierend auf Textvergleichen entwickelt, welches ein Mapping zwischen den
Elementen der Seiten definiert.
1
Model View Controller
Georg Bader
25
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.3: Paket controller
Der BrowserHelper wird aktiv, sobald in der Oberfläche der Befehl zum
Auslesen des HTML-Pfades eines Elements aus dem Browser gegeben
wurde. Daraufhin wird im Browser JavaScript ausgeführt, welches den
Quellcode des markierten Elementes mit zusätzlichen Tags umrahmt.
Hier kommt die Klasse Target ins Spiel, welche einen eindeutigen String
zur Verwendung als Identifikations-Tag zur Verfügung stellt. Der nächste
Schritt ist das Auslesen des Ziel-Elements aus dem HTML-Code. Um
den HTML-Pfad richtig bestimmen zu können, wird die Webseite mit
den Methoden des Crawlers heruntergeladen. Die Textbausteine der beiden Seiten werden verglichen, bis ein Mapping gefunden wurde, welches
die SWT-Browser-Seite auf eine Crawler-Seite abbildet. Anschließend
wird der HTML-Pfad des Zielelements mit Hilfe der statischen Klasse
HtmlPathHelper (Kapitel 5.4) auf der Crawler-Seite ausgelesen.
26
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
5.3
Grafische Benutzeroberfläche
Abbildung 5.4: Gui mit SWT-Browserfenster
Das Paket gui enthält jene Klassen, welche für die grafische Oberfläche benötigt werden. Abbildung 5.5 zeigt ein detailiertes Klassendiagramm aller im Paket gui enthaltener Klassen und Interfaces. Die
Hauptkomponente stellt die Klasse Gui dar. Diese implementiert das
Interface myProcessListener, welches eine Spezialierung des Interfaces
ErrorReceiver darstellt. Mit Hilfe des Interfaces ErrorReceiver werden
etwaige Fehlermeldungen, welche in anderen Klassen ihren Ursprung haben, an die Klasse Gui und somit an Benutzer weitergegeben. Das Interface myProcessListener gewährleistet, dass die implementierende Klasse
auf Ereignisse eines externen Prozesses reagieren kann. Verwendet wird
diese Funktionalität bei den Klassen ErrorStreamHandler und InputStreamHandler aus dem download Paket (Kapitel 5.6). Diese lesen die
Standardströme der externen Prozesse, wie zu Beispiel CVS, SVN oder
Git.
Die Klasse BrowserFrame erweitert den SWT-Browser [NW04] um die
klassischen Browserbedien- und Anzeigeelemente wie Vor-/Zurückknopf,
Adressleiste, Aktualisieren, Statusleiste, usw. Abbildung 5.4 zeigt die
grafische Oberfläche mit integriertem SWT-Browserfenster.
5.4
Datenverarbeitung
Das Paket data enthält die Klassen, welche verwendet werden um aus
den gewonnen Daten Objekte zu erzeugen, sowie statische Helfer-Klassen. Abbildung 5.6 zeigt eine Übersicht über das Zusammenwirken der
Klassen.
Georg Bader
27
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.5: Paket gui
28
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
HTML-Pfad
Die Klasse HtmlPath ist die Datenstruktur zur Speicherung eines Pfades zu einem HTML-Element innerhalb eines HTML-Dokuments. Wie
bereits im einführenden Kapitel besprochen, beruht das Programm auf
Basis der Erkenntnis, dass sich auf strukturgleichen Webseiten die gleiche Art von Information an der gleichen Stelle befindet. Anders ausgedrückt haben gleiche Arten von Informationen auf unterschiedlichen
Webseiten, wenn diese strukturgleich sind, den selben HTML-Pfad. Und
dieser wiederum wird abgebildet in HtmlPath-Objekten. Diese bestehen aus einer Sequenz von HTML-Tags realisiert als Stack von Strings
und der Position, welche die Anzahl des wiederholten Auftretens eines
Pfades wiederspiegelt. Die Reihenfolge der Tags ist von entscheidender
Bedeutung, da immer nur das oberste Element des Stacks verglichen werden kann. Aufgebaut wird der Stack durch die statische Helfer-Klasse
HtmlPathHelper, welche für ein Ziel-HTML-Element jeweils den StartTag des Vaterelements auf den Stack legt. Anschließend muss durch
Umkehrung dieses Vorganges ermittelt werden, wieviele Elemente sich
den selben Stack-Pfad teilen. Die Position des richtigen Elements plus
der Pfad-Stack reichen aus um den HTML-Pfad eindeutig in Form eines
HtmlPath-Objektes bestimmen zu können.
Pointer und Match
Die Klasse Pointer wird als Datenstruktur verwendet, um die einzelnen
Zeilen der Seitenbedingungsanzeige, siehe Kapitel 6.1, abzubilden. Eine
Zeile beinhaltet folgende Informationen:
• HTML-Pfad
• optional oder obligatorisch
• regulärer Ausdruck
• Repository-Technologie
• Titel
Alle diese Werte finden sich als entsprechende Attribute in der Klasse Pointer wieder. Da auch der Zusammenhang zwischen den einzelnen
Zeilen zueinander von Bedeutung ist, wurde eine Baumstruktur für diese Klasse gewählt. Dies erweitert die Pointer-Objekte jeweils um einen
Verweis auf ihre Vaterknoten bzw um ein Array von Verweisen auf ihre
Kindknoten. Durch die Klassifizierung der gefunden Seiten (siehe Kapitel 5.5) werden Match-Objekte angelegt, vorausgesetzt alle obligatorischen Pointer-Bedingungen konnten erfüllt werden. Ein Match-Objekt
stellt die Datenstruktur für einen kompletten Treffer dar. Ein Treffer
Georg Bader
29
KAPITEL 5. IMPLEMENTIERUNG
beinhaltet alle HTML-Elemente, welche durch die Seitenbedingungsanzeige spezifiziert wurden, sowie die Webseiten, auf welchen diese zu finden waren. In Kapitel 5 wurde bereits die Output-Anzeige aus Abbildung 6.2 erklärt, welche alle Treffer, also Match-Objekte, darstellt. Ein
Match-Objekt besteht aus einer Sammlung von Paaren bestehend aus
dem HTML-Element und dem zugehörigen Pointer, sowie einem Vektor aus Page-Objekten. Die Klasse Pointer spielt eine Doppelrolle, da
sie erstens eine Zeile der Seitenbedingung widerspiegelt und zweitens
die Referenzen über alle Match-Objekte verwaltet werden. Diese zweite
Rolle kommt allerdings nur einer speziellen Instanz der Pointer Klasse
zu, nämlich dem Wurzelknoten des Baumes. Die Beziehung zwischen den
Klassen Pointer und Match, wie unter Abbildung 5.6 zu sehen ist, trifft
also nicht auf alle Instanzen der Klasse Pointer zu. Der Wurzelknoten
Pointer verwaltet einerseits einen Vector von Match-Objekten und andererseits eine Hashmap, welche URL-Objekte auf Match-Objekte abbildet. Die Hashmap wird benötigt um Match-Objekte zu speichern, welche
bereits HTML-Elemente mit zugehörigen Pointern einer Tiefe ungleich
1 beinhalten, jedoch noch Einträge zu Pointern weiter oben im Baum
vermissen. Hier wird deshalb von Waisen-Machtes gesprochen. Dieses
Problem tritt auf, wenn Seiten, welche sich tiefer im Baum befinden,
zuerst gecrawlt werden. Sobald die Vater-Seite gefunden wurde, wird
auch das Link-Element entdeckt, welches auf eine Waisen-Seite zeigt.
Mit Hilfe der URL des Links-Elements kann das Waisen-Match-Objekt
aus der Hashmap ausgelesen werden.
DownloadItem
In der Phase des Herunterladens werden aus den Match-Objekten DownloadItems generiert. Diese bestehen aus einem ID-Objekt und einem
Vector aus Repo-Objekten. Aus einem vollständigem Match-Objekt wird
genau ein DownloadItem-Objekt erzeugt. Die Klasse DownloadItem wird
zur Generierung der Kommandosequenz, siehe Abbildung 6.3 herangezogen. Die Sequenz beginnt immer mit einem cd-Befehl2 , um die Repositories der verschiedenen Matches je in einen anderen Ordner ablegen
zu können. Die Wahl des Ordners wird bestimmt durch die Klasse ID.
Die ID-Objekte werden unter Heranziehung des HTML-Elements des
ersten Pointers der Tiefe 1 im Baum konstruiert, anders ausgedrückt,
dem HTML-Element, welches zur ersten Zeile der Seitenbedingungsanzeige gefunden wurde. Standardmäßig handelt es sich hierbei um den
Titeleintrag, siehe Abbildung 6.1. Da unter einigen Betriebssystemen
nicht alle Zeichen als Dateinamen erlaubt sind, werden nur die Zeichen
a-z, A-Z und 0-9 verwendet, sowie statt dem Leerzeichen. Dies wird
2
30
change directory
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
Abbildung 5.6: Paket data
Georg Bader
31
KAPITEL 5. IMPLEMENTIERUNG
realisiert durch folgende Zeilen Code:
String s = id.replace(" ", "_");
s=s.replaceAll("\\W", "");
Die Zeichenfolge \\W steht für eine vordefinierte Zeichenklasse der regulären Ausdrücke in Java. Die Länge des Ordnernamens wird außerdem beschränkt auf 40 Zeichen. Die relevanteren Befehle werden durch
die Klasse Repo bereitgestellt. Ein Repo-Objekt besteht aus dem String
für das Kommando und einem Element der Enumeration Technology.
Diese bestimmen sich durch die Wahl des HTML-Pfades und durch die
Art des Repositories. Je nach Technologie können mehrere Befehle nötig
sein um ein Repository vollständig herunterladen zu können. Bei CVS
zum Beispiel werden zwei Befehle verwendet. Der erste wird verwendet
für den Login und der zweite für das Auschecken. Beim Auscheck-Befehl
kann der Name eines gewünschten Modules übergeben werden. Das Programm ersetzt hier den Platzhalter modulename“ durch einen Punkt,
”
um statt einem bestimmten Modul alle herunterzuladen.
PrintHelper
Die statische Helfer-Klasse PrintHelper stellt die Funktionalität für
die diversen Schreib- und Leseoperationen auf Dateien zur Verfügung.
In Kapitel 5 wurde bereits über Methoden gesprochen, welche durch
die grafische Oberfläche angesprochen werden können, um gewonnene
Daten zu speichern und zu laden. Diese Methoden sind in der Klasse
PrintHelper implementiert. Um die Ergebnisse des Crawlvorganges zu
Serialisieren, wurde die Möglichkeit geschaffen, die gewonnen MatchObjekte in einer XML-Datei zu speichern. Eine damit generierte Datei
entspricht folgender Struktur:
<?xml version="1.0" ?>
<Match META1="meta1" META2="meta2" META3="meta3">
<pages page0="http://..." page1="http://..."></pages>
</Match>
Wobei META1 bis META3 als Platzhalter für die Titel der einzelnen
Zeilen der Seitenbedingungsanzeige zu verstehen sind. Ebenso sollen die
Werte der Attribute, welche sich zwischen den Anführungszeichen befinden, als Beispiel-Metadaten verstanden werden. Die Metadaten entsprechen den Funden der zugehörigen HTML-Pfade, welche, falls gesetzt,
den regulären Ausdrücken genügen. Die Auswertung der regulären Ausdrücke übernimmt die ebenfalls statische Helferklasse RegExpHelper.
Das XML-Element mit dem Namen pages beinhaltet ein Attribut mit
dem Titel page kombiniert mit einer fortlaufenden Zahl beginnend bei
0 für jede zum Match-Objekt gehörenden Webseite. Der Wert des Attributs entspricht der URL der Webseite.
32
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
5.5
WebCrawler
Das Paket crawler besteht aus nur einer Klasse, da der gesamte WebCrawler als ein eigenes Java-Projekt behandelt wurde, mehr dazu im
Kapitel 3.2. Die Klasse PathClassifier stellt eine Erweiterung von
WebSphinx dar, welche ihren Nutzen ausschließlich in Kombination mit
dem Extraktionsprojekt zur Schau stellen kann. Es handelt sich hierbei um eine Implementierung des Interfaces Classifier aus dem Paket websphinx. Das Interface garantiert die Implementierung der Methoden classify(Page):void und getPriority():float. Diese Methoden werden vom Crawler aufgerufen, sobald eine Seite fertig heruntergeladen wurde. Die Methode getPriority() dient lediglich dazu, eine
Reihenfolge der Ausführung der einzelnen Cassifier-Implementierungen
festzulegen. Die eigentliche Klassifizierung einer heruntergeladenen Webseite wird durch den Aufruf classify(Page) eingeleitet. Der Übergabeparameter ist vom Typ Page, welcher den Quellcode der Webseite sowie andere Seiten-spezifische Daten enthält. Die Idee hinter der Klasse
PathClassifier ist es, eine übergebene Seite zu testen, ob diese die Benutzer-spezifizierten HTML-Pfade enthält. Ist dies der Fall, soll dafür
ein Match-Objekt angelegt oder ein bestehendes ergänzt werden. Die
technische Umsetzung soll nun genauer erläutert werden.
Jedes Page-Objekt besitzt ein zugehöriges Link-Objekt, welches die URL
zu der Seite enthält, um diese herunterladen zu können. Zu Beginn der
classify Methode wird überprüft, ob dem Link der Seite, Match und/oder
Pointer Objekte angehängt wurden. Dies ist der Fall, wenn die Seite,
auf welcher der Link zu der aktuellen Seite zu finden war, bereits als
Match klassifiziert wurde. Ein angehängtes Pointer-Objekt zeigt an, auf
welchen Pointer, genauer auf welchen HTML-Pfad die Seite überprüft
werden soll. Konnte der Pfad gefunden werden, wird das zugehörige
Element dem angehängtem Match-Objekt hinzugefügt. Andernfalls wird
das Match-Objekt als nicht vervollständigbar markiert, vorausgesetzt,
der zu überprüfende Pointer war obligatorisch. Bei nicht auffindbaren
optionalen Pointern bedarf es keiner weiteren Behandlung. Falls Pointer
einer anderen Ebene im Baum noch nicht überprüft wurden, muss eine
entsprechende Suche eingeleitet werden. Hier werden grob zwei Fälle
unterschieden.
Fall 1: Die Pointer einer tieferen Ebene konnten noch nicht gefunden
werden.
Fall 2: Pointer-Objekte oberhalb bereits gefundener Elemente wurden
noch nicht gefunden.
Bei Fall 1 werden ausgehend von der aktuellen Seite, die HTML-Pfade
der Pointer, welche Referenzen auf Kindknoten enthalten, herangezogen,
Georg Bader
33
KAPITEL 5. IMPLEMENTIERUNG
um ihre Zielelemente speziell zu markieren. Es handelt sich bei diesen
Elementen um Links, welche auf andere Webseiten zeigen, welche wiederum die HTML-Pfade der Kind-Pointer befriedigen sollen. Um bei einer
Klassifizierung dieser Seiten den Zusammenhang zum aktuellen Match
nicht zu verlieren, werden den Links die jeweils zu überprüfenden Pointer
angehängt sowie eine Referenz auf das Match-Objekt. Weiters wird, um
den Download der Seite zu beschleunigen, der Link mit dem Label im”
portant“ versehen. Dies bewirkt auf Grund einer Erweiterung im Crawler eine Einreihung an vorderster Stelle der Download-Warteschlange.
Bei Fall 2 gestaltet sich die Suche nach den Seiten, welche auf die VaterPointer matchen, nicht so einfach. Dies liegt daran, dass in der Seitenbedingungsanzeige keine Links zu Vater-Elementen vorgesehen sind.
Dies ist auch nicht möglich, da nicht alle Webseiten über Links zu den
Seiten verfügen, auf welche sie selbst verlinkt wurden. Ein einfaches
Markieren eines weiterführenden Links wie unter Fall 1 ist also nicht
möglich. Stattdessen muss gewährleistet werden, dass wenn die VaterSeite durch den Crawler der Klassifizierung übergeben wird, der Zusammenhang zum aktuellen Match-Objekt nicht verloren geht. Hierzu wird
die URL der Seite, welche die Bedingungen des Pointers erfüllt, dessen
Vaterknoten noch nicht gefunden wurde, mit dem zugehörigen MatchObjekt verknüpft. Dies geschieht in Form eines Eintrags in der Hashmap für Waisen-Matches in der Klasse Pointer (siehe Kapitel 5.4). Bei
Klassifizierung einer Seite, welche den Vater-Pointer erfüllt, muss auch
ein weiterführender Link-Objekt gefunden werden. Dieser Link zeigt auf
die Seite, welche bereits im Match enthaltenen ist. Eine Suche in der
Waisen-Matches-Hashmap mit der URL des Links wird als Ergebnis das
Match-Objekt zurückliefern. Anschließend müssen nur noch die Funde
der aktuellen Seite zu diesem Match-Objekt hinzugefügt werden.
5.6
Download
Das Paket download enthält jene Klassen, welche verwendet werden, um
das Herunterladen der Repositories zu ermöglichen. Die Klasse Konsole
startet und überwacht externe Programme. Damit der Download mit
sämtlichen unterstützten Repository-Technologien funktioniert, müssen
auf dem System die Programme cvs, svn und git installiert sein (siehe
Kapitel 6.1). Ein Konsolen-Objekt wird erzeugt, indem der Konstruktor
mit einem String, bestehend aus einer Sequenz von Befehlen und einer
Referenz, auf ein myProcessListener-Objekt gestartet wird. Die Klasse Konsole erbt von der Klasse Thread, damit der Ausführungsstrang
nicht durch die Downloadüberwachung blockiert wird. Die Ausführung
des Konsolenthreads startet mit dem Aufsplitten der Befehle. Diese sind
34
Georg Bader
KAPITEL 5. IMPLEMENTIERUNG
durch einen Zeilenumbruch voneinander getrennt. Eine Besonderheit
stellt der Befehl cd zum Wechseln des Verzeichnisses dar, da dieser im
Gegensatz zu allen anderen Befehlen nur intern ausgeführt wird. Er bewirkt das Setzen des Pfad-Attributs auf den als Parameter übergebenen
Pfad. Alle weiteren Befehle werden mittels der Funktion exec des Runtime-Objekts in diesem Verzeichnis ausgeführt. Pro Befehl werden zwei
weitere Threads gestartet, nämlich der InputStreamHandler und der ErrorStreamHandler. Diese horchen auf dem entsprechenden Stream. Sendet der extern ausgeführte Prozess Informationen oder Fehlermeldungen, werden diese an das myProcessListener-Objekt weitergeleitet. Die
Klasse Gui implementiert das Interface myProcessListener. Der InputStreamHandler und der ErrorStreamHandler verfügen über eine Referenz auf das Gui-Objekt jedoch nur in Gestalt des myProcessListeners.
Mit diesen Klassen wurde die Funktionalität geschaffen, über welche der
Benutzer im Register Download, siehe Abbildung 6.3, verfügen kann.
5.7
Zusammenfassung
Zusammengefasst folgt die Ausführung des Programms dem folgenden
groben Arbeitsablauf: Der Benutzer markiert im Browserfenster einen
gewünschten Bereich. Mit Hilfe der Klassen BrowserHelper und HtmlPathHelper wird das markierte Element sowie dessen HTML-Pfad bestimmt. In der Seitenbedingungsanzeige können komplexe Anforderungen an die Suche gestellt werden. Diese können aus einer beliebig tiefen
Verschachtelung von HTML-Pfaden bestehen. In der Baumdarstellung
lässt sich ablesen, welche HTML-Pfade sich auf einer Seite befinden
müssen um als Treffer gewertet werden zu können, nämlich alle Geschwisterknoten. Hat ein Knoten Kinder, muss der zugehörige HTMLPfad einen Link als Ziel haben. Die konstruierten Bedingungen werden der Klasse PathClassifier in Form eines Baumes aus Pointern
übergeben. Diese unterzieht alle Seiten, welche durch den Crawler gefunden wurden, einer Klassifizierung. Enthält eine Seite alle gewünschten
Elemente, werden diese in einem Match-Objekt gespeichert. Der WebCrawler startet seine Suche auf der, durch den Benutzer ausgewählten
Webseite. Ausgehend von dieser Seite werden alle weiterführenden Links
in eine Warteschlange eingereiht. Diese Aufgabe wird dem WebCrawlerFramework namens WebSphinx übertragen, welches im nächsten Kapitel
beschrieben wird.
Georg Bader
35
Kapitel 6
Handbuch
In diesem Kapitel soll zunächst auf die Funktionalität des Prototypen
des Informationsextraktionsprogramms eingegangen werden, um im Anschluss die Installation sowie die Bedienung anhand konkreter Beispiele
zu beschreiben.
Das Programm bietet dem Benutzer eine grafische Oberfläche, in welche
ein Browserfenster eingebettet ist. In diesem kann in gewohnter Mannier zwischen den einzelen Webseiten navigiert werden. Im linken Teil
der Oberfläche befindet sich eine Steuerungseinheit. Dort kann sich der
Benutzer den HTML-Pfad (Kapitel 5.4) zu einem im Browserfenster
markiertem Element als Text anzeigen lassen. Dem HTML-kundigen
Anwender steht hier die Möglichkeit offen, den Pfad entsprechend seiner
Wünsche zu manipulieren. Nach einem Klick auf den Knopf Show Path
wird im Browserfenster nur noch der Bereich, welcher sich innerhalb des
Pfades befindet, dargestellt. Entspricht das angezeigte Element den Vorstellungen des Benutzers, kann der Pfad einem Element der hierarchisch
aufgebauten Seiten-Bedingungs-Anzeige hinzugefügt werden. Diese An-
Abbildung 6.1: Prototyp Seiten-Bedingungs-Anzeige
37
KAPITEL 6. HANDBUCH
zeige, wie unter Abbildung 6.1 zu sehen ist, zeigt die Bedingungen, welche an eine Seite gestellt werden, um als Treffer gewertet werden zu
können. Es gilt: Alle Einträge der selben Ebene gehören zu einer Seite.
Werden einem Eintrag Sub-Einträge hinzugefügt, wird dieser Eintrag
als Link auf einer Webseite gewertet. Der zugehörige HTML-Pfad sollte
ebenfalls auf einen Link matchen.
Die Bedingungen, die in Abbildung 6.1 zu sehen sind, beziehen sich auf
zwei verschiedene Seiten. Die erste Seite muss die Elemente beinhalten,
welche durch die HTML-Pfade der Einträge mit den Titeln titel“ und
”
link“ beschrieben werden. Die zweite Seite benötigt jedoch nur das
”
Element, welches durch den Eintrag repo“ beschrieben wird, um als
”
Treffer gewertet werden zu können.
Die Suche nach den Treffern startet, sobald der Crawlvorgang durch
einen Klick auf den Knopf start eingeleitet wird. Die gefundenen Seiten, welche den gestellten Bedingungen entsprechen, können im Register
output eingesehen werden. Abbildung 6.2 zeigt die einzelnen Treffer
durchnummeriert an Match0“ bis Match6“. Ein Treffer besteht bei
”
”
diesem Beispiel aus den zwei Seiten, welche durch die Bedingungen in
Abbildung 6.1 bestimmt wurden. Bei jedem Treffer lassen sich die Links
zu den zugehörigen Seiten anzeigen, sowie die gefundenen Elemente. Mit
einem Doppelklick lassen sich diese im Browserfenster darstellen. Bei einem Klick auf save lassen sich die Ergebnisse in Form einer XML-Datei
speichern. Der Knopf writeRepo bewirkt die Generierung der Dateien
SVN, CVS, Git und unknown im aktuellen Verzeichnis. Achtung: Bestehende Dateien gleichen Namens werden überschrieben! Diese Dateien
enthalten jene Elemente, welche im Input-Register als Repositories markiert wurden, sortiert nach Technologien. In der Datei unknown werden
jene Repository-Pfade abgelegt, welche weder durch den Benutzer noch
durch das Programm einer Technologie zugeordnet wurden.
Das Register Download (Abbildung 6.3) beinhaltet die Steuerung für
das automatisierte Herunterladen der Repositories. In das obere Textfeld lassen sich System-Befehle eintragen, welche sequenziell abgearbeitet werden, sobald auf download geklickt wurde. Eine Zeile beginnt mit
einem Kommando gefolgt von optionalen Parametern separiert durch je
ein Leerzeichen. Bei einem Klick auf generate wird das Textfeld mit
Befehlen zum automatisierten Herunterladen entsprechend der gefundenen Repositories gefüllt. Das Textfeld unterhalb zeigt, sobald der Downloadvorgang gestartet wurde, die Datemströme Standardausgabe und
Standardfehlerausgabe des aktuell exekutierten Programms an. Weiters
wird der Erfolg eines terminierten Prozesses durch Ausgabe des ExitValues angezeigt. Die Anzeige in Abbildung 6.3 zeigt die Beendigung
der erfolgreichen Ausführung des Befehls
cvs -z3 -d:pserver:[email protected]:
38
Georg Bader
KAPITEL 6. HANDBUCH
Abbildung 6.2: Output Anzeige
Abbildung 6.3: Register Download
Georg Bader
39
KAPITEL 6. HANDBUCH
/cvsroot/emulemorph co -P .
mit Exit-Value 0 an. Der nächste Befehl erfordert die Eingabe eines CVS
Passwortes. Die Kommunikation erfolgt mittels dem untersten Textfeldes und dem Knopf Send. Bei einem Klick darauf wird der Inhalt
des Textfeldes dem aktuell exekutierendem Prozess als Standardeingabe übergeben. Um das wiederholte Eingeben von Passwörtern dem Benutzer ersparen zu können, besteht die Möglichkeit automatisiert ein
Passwort an den Prozess zu senden, sobald dieser nach einem solchen
verlangt. Diese Option wird aktiviert durch Anhaken des Feldes auto
Psw. Der Vorgang des Herunterladens kann einige Zeit in Anspruch nehmen. Der Fortschritt lässt sich auf dem veränderten download Knopf
ablesen, welcher die Anzahl abgearbeiteter Befehle vor der Gesamtanzahl anzeigt. Sobald die gesamte Kommandosequenz durchlaufen wurde,
kann ein neuer Downloadvorgang gestartet werden.
6.1
Installation
Um das Java Programm prototyp.jar starten zu können wird die
Verfügbarkeit von Java-Bibliotheken in dem Verzeichnis prototyp lib
vorausgesetzt. Benötigt werden die Dateien 3rdPartyClass.jar und
swt.jar. Erstere wird benötigt für die Visualisierung des Crawlvorganges, welche bereits im WebCrawler Framework WebSphinx als Bibliothek genutzt wurde. Die Datei swt.jar ist erforderlich für den Start der
grafischen Oberfläche und insbesondere des Browserfensters. Wie bereits in Kapitel 3.4 aufgezeigt wurde, verwendet SWT zur Darstellung
von Oberflächenkomponenten native Funktionalität. Der Zugriff auf native Funktionalität erfolgt mit Hilfe der Bibliothek swt.jar. Diese muss
kompatibel mit der Architektur des ausführenden Rechners sein. Auf
der SWT-Webseite unter http://www.eclipse.org/swt/ werden Bibliotheken für alle gängigen Systemarchitekturen bereitgestellt.
Um den Prototypen inklusive der Download-Funktionalität nutzen zu
können werden die Kommandozeilenprogramme cvs, svn und git benötigt,
da diese durch das Programm aufgerufen werden.
6.2
Beispiel Sourceforge
Um die Entwicklungswebseite Sourceforge mit dem Prototypen erfolgreich zu Durchforsten kann wie folgt verfahren werden:
1. Öffnen der Webseite http://sourceforge.net/ im Browserfenster.
40
Georg Bader
KAPITEL 6. HANDBUCH
2. Öffnen eines Beispielprojekts.
3. Markierung des Projekttitels im Browserfenster. Hinweis: Die Markierung weniger Zeichen innerhalb des Elements reicht, um den
HTML-Pfad für das ganze Element auszuwählen.
4. Den HTML-Pfad durch Klicken der Schaltfläche Path from Selection berechnen und anzeigen lassen. Hinweis: Zur Überprüfung
des HTML-Pfades stehen folgende Möglichkeiten zur Verfügung:
• Durchschauen des HTML-Pfades im Textfeld
• Durch Klicken der Schaltfläche Show Path wird der Inhalt des
Pfades auf der aktuellen Seite angezeigt. Mit der Schaltfläche
Back im Browserfenster kann zur vorherigen Seite zurückgekehrt werden.
5. Auswahl einer Zeile in der Seitenbedingungsanzeige. Hinweis: Durch
einen Doppelklick lassen sich die einzelnen Felder einer Zeile bearbeiten. Das Feld für den HTML-Pfad lässt sich durch das separate
Textfeld editieren. Um Änderungen zu übernehmen muss dies mit
der Schaltfläche set Path bestätigt werden.
6. Den angezeigten Pfad hinzufügen durch Klicken der Schaltfläche
set Path
7. Markierung des Links zum Repository im Browserfenster + Klicken
der Schaltfläche Path from Selection
8. Kontrolle des HTML-Pfades: Die letzte Zeile des HTML-Pfades
muss auf <a> lauten, da das darauf passende Element ein Link
sein soll.
9. Hinzufügen des HTML-Pfades zu einem Eintrag in der Seitenbedingungsanzeige, welcher Subeinträge beinhalten soll.
Georg Bader
41
KAPITEL 6. HANDBUCH
10. Durch Anklicken des Links die Seite mit dem Pfad zum Repository
öffnen.
11. Den Pfad zum Repository auswählen und den Pfad berechnen lassen.
12. Einen Subeintrag zum Eintrag, welcher den Link symbolisiert auswählen oder durch Klicken der Schaltfläche add Item generieren.
13. Die Klassifizierung dieses Eintrages auf SVN or CVS or GIT setzen. Den HTML-Pfad zu diesem Subeintrag hinzufügen.
14. Auswahl der Startseite des Crawlvorganges: Im Browserfenster eine Webseite auswählen (Webserver muss selbe IP-Adresse haben),
von welcher aus viele Soll-Seiten mit möglichst wenigen Klicks erreicht werden können.
15. Mit einem Klick auf die Schaltfläche start beginnt die Suche.
16. Der Crawlvorgang lässt mit einem Klick auf die Schaltfläche graph
visuell verfolgen. Durch einen Doppelklicken auf Seiten-Icons öffnen
sich diese im Browserfenster. Im Register Output erscheinen die
gefundenen Treffer.
6.3
Beispiel java.net
Eine Suche auf der Webseite java.net (http://java.net/) kann größtenteils analog zum Beispiel Soureforge, siehe Kapitel 6.2, erfolgen. Einige
Anpassungen sind jedoch noch nötig, da die benötigten Kommandos
zum Herunterladen von CVS-Repositories sich nicht ausschließlich in einem HTML-Element befinden, wie Abbildung 6.4 veranschaulicht. Der
Trick lautet hierbei einen optionalen Eintrag zu erstellen, welcher das
zweite CVS-Kommando finden soll.
42
Georg Bader
KAPITEL 6. HANDBUCH
Abbildung 6.4: Die CVS-Kommandos befinden sich in zwei HTML-Elementen.
Abbildung 6.5: Ein zusätzlicher optionaler Eintrag
Optionale Einträge unterscheiden sich von obligatorischen durch einen
fehlenden Hacken vor dem Titel. Der optionale Eintrag soll als Subeintrag zum Link-Eintrag gewählt werden. Eine Suche mit dem Ziel Titel
und Repository auf java.net zu extrahieren, wird durch Bedingungen,
wie unter Abbildung 6.5 zu sehen ist bestimmt.
Georg Bader
43
Kapitel 7
Schlusswort und Ausblick
Ziel der Arbeit war es, ein Verfahren zu entwickeln, welches es ermöglicht,
Opensourcesoftwareprojekte auf Sourcecodeportalen im Internet ausfindig zu machen, dessen Metadaten zu erfassen sowie Funktionalität für
das automatisiere Downloaden zur Verfügung zu stellen. Mit der ersten
Implementierung des Repositoryextraktionsprogramms wurde ein funktionsfähiger Prototyp geschaffen, welcher die angestrebten Ziele verwirklicht. Der Prototyp ermöglicht dem Benutzer die grafische Markierung
von HTML-Elementen in einem Browserfenster. Mit Hilfe der Seitenbedingungsanzeige kann eine baumartige Struktur von verknüpften Bedingungen für einen Treffer gestaltet werden. Die Suche basiert auf einem WebCrawler, welcher mit dem WebSphinx-Webcrawlerframework
entworfen wurde. Jede gecrawlte Seite wird einer Klassifizierung unterzogen, welche diese auf das Auftreten bestimmter HTML-Pfade untersucht. Wurden alle benötigten Elemente gefunden, wird die Seite als
Treffer gewertet. Ein Treffer setzt sich je nach Komplexität der Bedingungen aus vielen HTML-Elementen zusammen, welche auf verschiedenen Webseiten ihren Ursprung haben können. Die erzielten Treffer lassen sich in Form einer XML-Datei speichern. Die aufgespürten Repositories können anschließend heruntergeladen beziehungsweise auf den neuesten Stand gebracht werden. Dieser Vorgang setzt auf die Verfügbarkeit
von Versionsverwaltungssystemen. Benötigt werden die Kommandozeilenprogramme cvs, svn und git. Um die grafische Oberfläche und insbesondere das integrierte Browserfenster starten zu können, wird das
Oberflächenwerkzeug SWT verwendet.
Aufgrund der Verwendung von nativer Funktionalität durch SWT kann
die Darstellung von Webseiten im Browserfenster von System zu System
variieren. Dies kann unter Umständen zu Problemen bei der korrekten
Bestimmung des HTML-Pfades eines markierten Elements im Browserfenster führen. Fehlerquellen für die korrekte HTML-Pfad-Bestimmung
sind außerdem die unterschiedlichen Stile der Quellcodepräsentation von
45
KAPITEL 7. SCHLUSSWORT UND AUSBLICK
Webseiten durch die verwendeten HTML-Parser sowie die browserspezifischen Eigenheiten der HTML-Requests zum Anfragen von Webseiten. Ein möglicher Ansatz zur Verbesserung dieser Problematik wäre
die Schaffung einer gemeinsamen Instanz zum Anfragen, Herunterladen
und Parsen von Webseiten, da die aktuelle Implementierung einerseits
für die Darstellung im Browserfenster native Funktionalität verwendet
und andererseits die Routinen von WebSphinx für alle Belange des WebCrawlers.
Außerdem möglich wäre das automatisierte Einspeisen der Ergebnisse in eine Datenbank, welche beim Start des Programms alle bekannten Repositories auf Änderungen überprüft und diese gegebenenfalls auf
den neuesten Stand bringt, sowie Funktionen, welche den aufgespürten
Quellcode analysieren und klassifizieren, um bei gezielten Suchen in der
Datenbank den entsprechenden Programmcode zurückliefern zu können.
Mit diesen Erweiterungen wäre es ebenfalls möglich mehrere Instanzen
des Extraktionsprogramms auf verschiedenen Rechnern laufen zu lassen,
um in kürzerer Zeit größere Mengen an Daten gewinnen zu können.
46
Georg Bader
Literaturverzeichnis
[BFG01]
R. Baumgartner, S. Flesca and G. Gottlob: Visual Web Information Extraction with Lixto, VLDB ’01: Proceedings of
the 27th International Conference on Very Large Data Bases, Morgan Kaufmann Publishers Inc., San Francisco, CA,
USA, 2001, pages 119–128.
[BTMC04] K. Bontcheva, V. Tablan, D. Maynard and H. Cunningham:
Evolving GATE to meet new challenges in language engineering, Nat. Lang. Eng., volume 10(3-4), (2004), pages 349–
373.
[CGM02]
J. Cho and H. Garcia-Molina: Parallel crawlers, WWW ’02:
Proceedings of the 11th international conference on World
Wide Web, ACM, New York, NY, USA, 2002, pages 124–
135.
[Cot04]
V. Cothey: Web-crawling reliability, Journal of the American
Society for Information Science and Technology, volume 55,
(2004), pages 1228–1238.
[Eik99]
L. Eikvil: Information Extraction from World Wide Web A Survey, Technical report, Norwegian Computing Center,
P.B. 114 Blindern, N-0314 Oslo, Norway, 1999.
[Gru86]
D. Grune: Concurrent Versions System, A Method for Independent Cooperation, Technical report, IR 113, Vrije Universiteit, 1986.
[GRVB98] J.-R. Gruser, L. Raschid, M. E. Vidal and L. Bright: Wrapper
Generation for Web Accessible Data Sources, COOPIS ’98:
Proceedings of the 3rd IFCIS International Conference on
Cooperative Information Systems, IEEE Computer Society,
Washington, DC, USA, 1998, pages 14–23.
[Java]
Java.net: Glassfish, URL https://glassfish.dev.java.
net/, [Online; Stand 9. Nov 2010].
47
LITERATURVERZEICHNIS
[Javb]
Java.net: jdk, URL https://jdk.dev.java.net/, [Online;
Stand 9. Nov 2010].
[Javc]
Java.net: jini, URL https://jini.dev.java.net/, [Online;
Stand 9. Nov 2010].
[KRW10]
A. King, A. Ruder and A. Waterland: Git Community Book,
Git Community, 2010.
[KT02]
S. Kuhlins and R. Tredwell: Toolkits for Generating Wrappers, NODe ’02: Revised Papers from the International Conference NetObjectDays on Objects, Components, Architectures, Services, and Applications for a Networked World,
Springer-Verlag, London, UK, 2002, pages 184–198.
[MB98]
R. C. Miller and K. Bharat: SPHINX: a framework for
creating personal, site-specific Web crawlers, Comput. Netw.
ISDN Syst., volume 30(1-7), (1998), pages 119–130.
[NH02]
M. Najork and A. Heydon: High-performance web crawling,
(2002), pages 25–45.
[NW04]
S. Northover and M. Wilson: Swt: the standard widget toolkit, volume 1, Addison-Wesley Professional, 2004.
[PCSF08] C. Pilato, B. Collins-Sussman and B. Fitzpatrick: Version
Control with Subversion, O’Reilly Media, Inc., 2008.
[Soua]
Sourceforge: 7-Zip, URL http://sourceforge.net/
projects/sevenzip/, [Online; Stand 9. Nov 2010].
[Soub]
Sourceforge: Azureus / Vuze, URL http://sourceforge.
net/projects/azureus/, [Online; Stand 9. Nov 2010].
[Souc]
Sourceforge: bitTorrent, URL http://sourceforge.net/
projects/bittorrent/, [Online; Stand 9. Nov 2010].
[Soud]
Sourceforge: eMule, URL http://sourceforge.net/
projects/emule/, [Online; Stand 9. Nov 2010].
[Soue]
Sourceforge:
gate,
URL
http://sourceforge.net/
projects/gate/, [Online; Stand 9. Nov 2010].
[Voß06]
S. Voß: Extraktion semantischer Informationen aus WIKISystemen, Master’s thesis, Frankfurt am Main, 2006.
[Wik10]
Wikipedia: Repository — Wikipedia, Die freie Enzyklopädie, 2010, URL http://de.wikipedia.org/w/index.
php?title=Repository&oldid=75614998, [Online; Stand
9. Juli 2010].
48
Georg Bader