Bachelorarbeit

Christian Linde

Transformation der vorhandenen Stundenplandaten zur Inkludierung im Datenbank-Service in Haskell. Prototypische Implementierung in Spirit

Institut Fachbereich Referent Korreferent Semester Matr.-Nr.

Fachhochschule Schmalkalden Informatik Prof. Dr. Braun Prof. Dr. Stiefel 6 280242

05.09.2011

Inhaltsverzeichnis
1 Einleitung 1.1 Der aktuelle Stundenplan . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Grnde fr einen neuen Stundenplan . . . . . . . . . . . . . . . . . . 1.3 Ziele, die diese Bachelorarbeit erreichen soll . . . . . . . . . . . . . . 2 Grundlagen 2.1 Parser-Techniken 2.2 Haskell . . . . . . 2.3 Spirit . . . . . . . 2.4 RESTful Service 1 2 3 4 5 5 5 6 6 8 8 11 11 12 12 13 13 15 17 17 18 19 21 22 23 26 26 26 28 28 29 29 30

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 Vorbetrachtung 3.1 Die Stundenplan-HTML-Daten . . . . . . . . . 3.2 Verfahren zur Transformation der HTML-Daten 3.2.1 blaze-html . . . . . . . . . . . . . . . . . 3.2.2 Parsec . . . . . . . . . . . . . . . . . . . 3.2.3 HaXml . . . . . . . . . . . . . . . . . . . 3.2.4 xhtml . . . . . . . . . . . . . . . . . . . 3.2.5 TagSoup . . . . . . . . . . . . . . . . . . 3.3 Beschreibung des verwendeten Verfahrens . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 Transformation der HTML-Stundenplandaten 4.1 Entwicklung einer Zwischenstruktur . . . . . . . . . . . . . 4.2 Transformation der HTML-Struktur . . . . . . . . . . . . . 4.3 Der Zustandsautomat . . . . . . . . . . . . . . . . . . . . . 4.4 Implementierung des Zustandsautomaten . . . . . . . . . . 4.5 Entwicklung der internen Datenstruktur . . . . . . . . . . 4.6 Zwischenstruktur in interne Datenstruktur transformieren . 5 Erweiterung und Speicherung der internen Datenstruktur 5.1 Erweiterung der internen Datenstruktur . . . . . . . . 5.1.1 Ausung der Dozenten-Bezeichnung . . . . . . 5.1.2 Beginn und Ende einer Veranstaltung . . . . . . 5.1.3 Ablaufdatum der Veranstaltung . . . . . . . . . 5.1.4 Studiengangname und classID . . . . . . . . . . 5.2 Exportieren der interne Datenstruktur . . . . . . . . . 5.3 bertragung der JSON-Daten zum RESTful Service . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 Resmee

32

A Anhang 34 A.1 Implementierung des Zustandsautomaten . . . . . . . . . . . . . . . . 34 Literatur Ehrenwrtliche Erklrung 41 42

II

1 Einleitung
Diese Bachelorarbeit ist ein Teilprojekt des Projektes Spirit. Der Entwicklungsname dieses Teilprojektes ist Migrate. Das Projekt Spirit ist eine fakulttsweite Plattform fr Studenten, die Zugri auf den Stundenplan oder aktuelle Informationen der Fakultt ermglicht. Die Aufgabe dieser Bachelorarbeit ist es, eine Schnittstelle zum Import des aktuellen Stundenplan-Formates in das neue Datenbanksystem von Spirit zu bilden. Es muss mglich sein, sowohl die Daten aus dem vorhergehenden Stundenplanungstool als auch die Daten des neuen Stundenplanungstools, das als Teilprojekt von Spirit in Planung ist, in das neue Datenbanksystem zu importieren. Da nicht abzusehen ist, wann das neue Datenbanksystem verfgbar ist, soll nur eine prototypische Implementierung des RESTful Services, der als Verbindung zur Datenbank verwendet wird, umgesetzt werden. Des Weiteren soll es im Programm die Mglichkeit geben, die Stundenplandaten als JSON zu exportieren. Fr die Umsetzung des Teilprojektes von Spirit kann jede Programmiersprache verwendet werden, mit der es mglich ist Dateien einzulesen und zu verarbeiten, sowie jede, die die Mglichkeit bietet Dateien zu schreiben. Fr das Teilprojekt ist die Programmiersprache Haskell vorgegeben. Damit ein besseres Verstndnis von den verschiedenen Teilprojekten von Spirit entstehen kann, sind diese in Abbildung 1.1 dargestellt.

KAPITEL 1. EINLEITUNG

Mobile Apps

EmployeeWeb

PlanningWeb

MIgrate

StudWeb

RESTful Service
Database alte Stundenplanung

Prolog
LCD-Pro
CARD READER AUDIO
LINE-IN PHONE MIC

SATA

USB
EJECT

DVD-RW
POWER

SELECT MENU

libSpirit
LCD-Pro

Esc

F1
~

F2
`
!
Tab

F3
1
@

F4
2
#

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

Shift Alt Ctrl

F7 F8

F11 F12 F9 F10 +

_

Scroll Lock PrintScrn SysRq

Pause

NumLock
Break

CapsLock

Scroll Lock

Insert

Home

PageUp Delete End

NumLock
PageDown

* 7

8 4

Home

PgUp

6 1
End

+ 2 0 3
PgDn Ins . Enter Del

Shift Alt Gr

Ctrl

C
LCD-Pro

CARD READER

AUDIO
LINE-IN PHONE MIC

SATA

USB
EJECT

DVD-RW
POWER

SELECT MENU

Esc

F1
~

F2
`
!
Tab

F3
1
@

F4
2
#

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

Shift Alt Ctrl

F7 F8

F11 F12 F9 F10 +

_

Scroll Lock PrintScrn SysRq

Pause

NumLock
Break

CapsLock

Scroll Lock

Insert

Home

PageUp Delete End

NumLock
PageDown

* 7

8 4

Home

PgUp

6 1
End

+ 2 0 3
PgDn Ins . Enter Del

Shift Alt Gr

Ctrl

CARD READER

AUDIO
LINE-IN PHONE MIC

SATA

USB
EJECT

DVD-RW
POWER

SELECT MENU

Esc

F1
~

F2
`
!
Tab

F3
1
@

F4
2
#

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

Shift Alt Ctrl

F7 F8

F11 F12 F9 F10 +

_

Scroll Lock PrintScrn SysRq

Pause

NumLock
Break

CapsLock

Scroll Lock

Insert

Home

PageUp Delete End

NumLock
PageDown

* 7

8 4

Home

PgUp

6 1
End

+ 2 0 3
PgDn Ins . Enter Del

Shift Alt Gr

Ctrl

Florian Schuhmann

Abbildung 1.1: Projektbersicht von Spirit. Quelle: Abbildung von Florian Schuhmann.

1.1 Der aktuelle Stundenplan

Die Fachhochschule Schmalkalden bietet den Studenten der Fakultt Informatik einen Stundenplan an. Die Darstellung des Stundenplans wurde in der Beschreibungssprache HTML umgesetzt. Die verwendete Version ist laut W3C Validator1 HTML 4.01 Transitional. Bei einem Test mit dem Bachelor Informatik Stundenplan des sechsten Semesters wurden auf der Seite des W3C Validator 120 Fehler und 6 Warnungen gefunden. Das zeigt, dass ein fehlertolerantes Verfahren zum Transformieren der HTML-Daten bentigt wird. Der Stundenplan dient den Studenten der Fakultt Informatik als Leitwerk fr ihre Veranstaltungen, welches den Studenten ber das Internet angeboten wird.

Vgl. W3C

Seite 2

KAPITEL 1. EINLEITUNG

1.2 Grnde fr einen neuen Stundenplan

Die Darstellung des Stundenplans soll durch ein weiteres Teilprojekt von Sprit erneuert werden. Auerdem soll die Generierung der Daten durch zustzliche Informationen erweitert werden. Das begrndet sich dadurch, dass mehr Informationen zusammengetragen werden, die an einem Punkt gebndelt werden sollen. Beispiel dafr ist, dass im Moment auf drei HTML-Seiten Informationen zu ermitteln sind, um herauszunden, wann welche Veranstaltung stattndet, welcher Veranstaltungsgruppe ein Student zugeteilt ist und wie die vollstndige Bezeichnung der Veranstaltung lautet. Des Weiteren gibt es aktuell fr die Studenten keine Mglichkeit, im Stundenplan nur die Veranstaltungen fr eine bestimmte Gruppe anzeigen zu lassen. Damit ist die Darstellung des Stundenplans unbersichtlich, da immer alle Veranstaltungen auf einer Seite dargestellt werden, egal ob diese wchentlich oder alle zwei Wochen stattnden. In Abbildung 1.2 ist ein Ausschnitt des Stundenplans der Bachelor Informatik Studenten des sechsten Semesters dargestellt. In der Abbildung ist zu erkennen, dass alle Veranstaltungen in einer Anzeige zu sehen sind. Damit wird eine schnelle Informationsgewinnung, zum Beispiel um herauszunden was die nchste Veranstaltung fr einen bestimmten Studenten ist, erschwert. Ein kleines Beispiel um das Problem zu verdeutlichen ist: Ein Student ist in der Vorlesungsgruppe Zwei eingeteilt und mchte wissen, wann eine Veranstaltung stattndet, in der eine Gruppen-Einteilung vorgenommen wird. Dieser Student hat in der aktuellen Darstellungsform nur die Mglichkeit sich alle Veranstaltungen anzuschauen und die fr ihn wichtigen herauszusuchen. Dabei muss er sich zustzlich mit den Veranstaltungen auseinandersetzen, an den Studenten anderer Gruppen teilnehmen. In der neuen Variante des Stundenplans hat der Student die Mglichkeit, eine bestimmte Gruppe durch einen Filter auszuwhlen und dann ausschlielich die Veranstaltungen fr diese Gruppe angezeigt zu bekommen. Somit wird dem Studenten Zeit gespart und der Stundenplan bersichtlicher. Des Weiteren sind die Daten derzeit nur ber die HTML-Stundenplan-Seite zu erreichen. Spter werden die Daten auch direkt ber den RESTful Service abfragbar sein.

Seite 3

KAPITEL 1. EINLEITUNG

Abbildung 1.2: Stundenplan BaI6 Ausschnitt. Quelle: http:// sund.de/ steffen/ plan/ s_bai6.html.

1.3 Ziele, die diese Bachelorarbeit erreichen soll

Das Ziel dieser Bachelorarbeit ist es eine Stundenplan-HTML-Tabelle zu verarbeiten und die relevanten Daten aus dieser Tabelle in einem weiterverarbeitbarem Dateiformat, wie JSON, zu exportieren. Bei der Umsetzung des Projektes muss darauf geachtet werden, dass die Verarbeitung der Stundenplan-HTML-Tabelle und der Export der Daten in ein Dateiformat getrennt werden. Der Grund fr die Trennung ist, dass der neue Stundenplan-Generator, auch Stundenplanungstool genannt, die Funktionen zum Exportieren der Daten nutzen soll.

Seite 4

2 Grundlagen
Das Kapitel Grundlagen soll dem Leser ein Grundverstndnis ber das in der Bachelorarbeit behandelte Themengebiet geben. Dabei soll auf die Themen ParserTechniken, Haskell, Spirit und RESTful Service eingegangen werden.

2.1 Parser-Techniken
Fr einen Computer ist jede Eingabe zu Beginn nur ein Text, mit dem er nichts anfangen kann. Deshalb werden Parser-Techniken verwendet, um aus einer Eingabe eine syntaktische Struktur zu gewinnen.1 Ein Anwendungsbeispiel fr den Einsatz von Parsern, ist HTML. Mit HTML alleine kann ein Computer nichts anfangen. An dieser Stelle wird ein Parser bentigt. Dieser ermglicht dem Computer die HTMLDatei zu interpretieren und zu analysieren. Somit kann der Inhalt der HTML-Datei weiterverarbeitet und zum Beispiel durch einen Browser angezeigt werden.2

2.2 Haskell
Die Programmiersprache Haskell gehrt zu der Gruppe der funktionale Programmiersprachen. Wenn man die Einteilung der Programmiersprachen nach imperativen und deklarativen Sprachen betrachtet, so sind die funktionalen Sprachen eine Untergruppe der deklarativen Sprachen. Zu dieser Kategorie gehrt auch Lisp. Bei funktionalen Programmiersprachen handelt es sich um Programme, die ausschlielich aus Funktionen bestehen. Durch diesen Sachverhalt, ist es mglich, die aus der

1 2

Vgl. Schmitt Vgl. Verfasser, Parser

KAPITEL 2. GRUNDLAGEN

imperativen Programmierung bekannten Nebenwirkungen zu vermeiden. Eine Nebenwirkung imperativer Programmierung ist zum Beispiel der Seiteneekt. Imperative Programmiersprachen sind zum Beispiel C und Java. Die Programmiersprache Haskell, als Vertreter der funktionalen Sprachen, hat folgende Vorteile: Sie ermglicht Funktionen hherer Ordnung, dadurch wird eine starke Wiederverwendung von Programmteilen ermglicht. Weiterhin fhrt die oben erwhnte Abwesenheit von Seiteneekten zur Reinheit der Sprache. Durch die Reinheit der Sprache, wird das Beweisen ber Programmeigenschaften erleichtert. Haskell bietet des Weiteren ein starkes Typsystem. Dies ist ein groer Vorteil, da dadurch viele Fehler bereits durch den Compiler erkannt werden knnen.3

2.3 Spirit
Das Projekt Spirit auch spirit@fhs genannt, stellt eine Informationsplattform fr die Studenten der Fakultt Informatik der Fachhochschule Schmalkalden bereit. Bisher bietet die Plattform Informationen ber aktuelle Mitteilungen der Fakultt Informatik, sowie die Stundenplne fr die Studenten der Fakultt. Die Informationsplattform ist im Internet unter http://spirit.fh-schmalkalden.de/ erreichbar. Das Projekt Spirit gliedert sich in verschiedene Teilprojekte die von verschiedenen Studenten und Dozenten der Fachhochschule Schmalkalden geplant und umgesetzt werden. Aktuell existieren die folgenden Teilprojekte: Core, News, StudWeb, EmployeeWeb, PlanningWeb, Data, Mobile, DistributedCalc, Migrate, LibSpirit.
4

2.4 RESTful Service

Der RESTful Service ist ein zentrales Modul im Projekt Spirit. Es ist fr die Datenverwaltung zustndig, so dass die Anwendungen nicht ber Wissen der untergeordneten Datenspeicherungssysteme verfgen mssen. REST stammt aus dem Jahre 2000 und basiert auf einer Dissertation von Roy Fielding. Als Anwendungsschicht-Protokoll fr REST, dient meist HTTP. Eine Eigenschaft von REST ist, dass keine Sitzungsverwaltung ber Cookies bei der Kommunikation
3 4

Vgl. Verfasser, Funktionale Programmierung(Wikipedia), Lengauer Vgl. Braun

Seite 6

KAPITEL 2. GRUNDLAGEN

im World Wide Web verwendet wird. Das REST-System gilt in seiner Konsequenz als eine Richtlinie fr die Nutzung von Web-Standards.5 REST setzt auf ein zustandsloses Client/Server-Protokoll. Dabei enthlt jede HTTPBotschaft alle Informationen, die notwendig sind, um die Nachricht zu verstehen. Deshalb muss weder der Server noch der Client Zustandsinformationen zwischen zwei Nachrichten speichern. Eine derartig strikte Trennung der Zustndigkeiten zwischen Client und Server fhrt dazu, dass ein REST-konformer Webservice als zustandslos (stateless) bezeichnet werden kann 6

5 6

Vgl. Verfasser, REST Verfasser, REST

Seite 7

3 Vorbetrachtung
In der Vorbetrachtung werden alle grundlegenden Entscheidungen getroen, wie die Auswahl eines geeigneten Transformationsverfahrens.

3.1 Die Stundenplan-HTML-Daten

Die Stundenplan-Daten sind als HTML-Dateien verfgbar. Diese knnen ber die entliche Fachhochschulseite im Internet abgerufen werden. Ein Ausschnitt des Tabellenaufbaus aus der HTML-Datei, ist im Listing 3.1 abgebildet. Wie im Listing 3.1 in Zeile 8 bis 16 zu sehen ist, wird ein Slot in der Tabelle wieder durch eine Tabelle abgebildet. Somit ist es mglich mehrere Veranstaltungen in einen Slot zu legen. Der Grund dafr ist, dass eine Untertabelle vorhanden ist. Dieser Umstand muss bei der spteren Verarbeitung bedacht werden.
1

< TABLE B R E =1 W D H O DR I T =100% c e l l s p a c i n g=0 b o r d e r c o l o r d a r k=#FFFFFF b o r d e r c o l o r l i g h t =#008000>

< TR align=center> < >Z e i t</TH < >Montag</TH < >D i e n s t a g</TH TH > TH > TH > < >Mittwoch</TH < >Donnerstag</TH < >F r e i t a g</TH TH > TH > TH > </TR < > TR align=center>

< >08.15 09.45</TD TD TD >< >&nbsp ;</TD < >&nbsp ;</TD > TD > < > TD < TABLE B R E =1 W D H O DR I T =100% c e l l s p a c i n g=0 b o r d e r c o l o r d a r k=# FFFFFF>

< TR align=center>< ><font color=#A52A2A> TD <img border=0 src=" b i l d e r / monitor . g i f " width=17 height=17> DBS&nbsp ; V1

10

11

< >WKST BR &nbsp ; <B >g</B >&nbsp ; 1

12

KAPITEL 3. VORBETRACHTUNG

13

< >K n o l l e </ font> BR </TD > ... </TABLE ></TD > ... </TABLE ></TD > Listing 3.1: Tabellenaufbau des alten Stundenplans

14

15

16

17

18

Ein weiteres Problem ist, dass die Darstellungen der Informationen unterschiedlich sind. Das liegt unter anderem daran, dass Veranstaltungen wchentlich oder alle zwei Wochen angeboten werden knnen. Ein Beispiel dazu ist im Listing 3.2 abgebildet.
1

< ><font color=#A52A2A> TD <img border=0 src=" b i l d e r / monitor . g i f " width=17 height=17>DBS& nbsp ; V1

< >WKST BR &nbsp ; <B >g</B >&nbsp ; 1 < >K n o l l e </ font> BR </TD >

< ><font color=#A52A2A> TD <img border=0 src=" b i l d e r / monitor . g i f " width=17 height=17>DBS& nbsp ; V1

10

< >WKST BR &nbsp ; <B >w</B >&nbsp ; < >K n o l l e </ font> BR </TD > Listing 3.2: Unterschied wchentlich oder alle zwei Wochen

11

12

13

Seite 9

KAPITEL 3. VORBETRACHTUNG

Ein weiterer Grund fr die unterschiedlichen Darstellungen der Informationen ist, dass Vorlesungen und bungen im Stundenplan verschieden dargestellt werden. Der Unterschied besteht darin, dass bei einer bung meistens eine Gruppeneinteilung vorgenommen wird, was bei Vorlesungen selten vorkommt. Trotzdem knnen Gruppenaufteilungen fr Vorlesungen nicht ausgeschlossen werden. Ein Beispiel dazu ist im Listing 3.3 abgebildet. In Zeile 5 ist dargestellt, dass die bung in einer ungeraden Kalenderwoche fr die Gruppe Eins statt ndet. In Zeile 13 wird eine Vorlesung ohne Gruppeneinteilung angeboten.
1

< > <font color=#2D71FF> TD <img border=0 src=" b i l d e r / monitor . g i f " width=17 height=17> SWEProg&nbsp ; V3 < >PC2&nbsp ; BR <B >u</B >&nbsp ; 1 < >Braun </ font> BR </TD >

< ><font color=#A52A2A> TD <img border=0 src=" b i l d e r / buch . g i f " width=24 height=14> SWEProg&nbsp ; V2 < >H0216&nbsp ; BR <B >g</B >&nbsp ; < >Recknagel </ font> BR </TD > Listing 3.3: Unterschied bung/Vorlesung

10

11

12

13

14

15

Beim Verarbeiten der Veranstaltungen muss zustzlich beachtet werden, dass die Information, ob ein eingetragener Termin eine Vorlesung oder bung ist, anhand eines Bildverweises entschieden wird. Dies kann man im Listing 3.3 in Zeile 2 und 10 feststellen. Eine weitere Schwierigkeit beim Erstellen des Stundenplans ist, dass die Darstellungsform des HTML-Codes nicht einheitlich ist. Das heit, dass bei den HTMLTag Informationen einmal der Attribut-Name gefolgt von einem Gleichheitszeichen und dem HTML-Tag Wert dargestellt ist und ein anderes Mal ist der HTML-Tag Wert in Anfhrungsstrichen eingeschlossen. Dieser Sachverhalt muss beim Parsen

Seite 10

KAPITEL 3. VORBETRACHTUNG

der HTML-Tags bercksichtigt werden. Ein Beispiel fr die verschiedenen Darstellungen ist im Listing 3.4 zu sehen.
1

a t t r i b u t n a m e=v a l u e a t t r i b u t n a m e=" v a l u e " Listing 3.4: Darstellungsform des HTML Codes

3.2 Verfahren zur Transformation der HTML-Daten

Nach dem die wichtigsten Eckpunkte des HTML-Stundenplans analysiert wurden, muss nun ein geeignetes Verfahren gefunden werden, dass die Transformation der HTML-Daten ermglicht. Dabei liegt das Kriterium fr ein gesuchtes Verfahren bei der fehlertoleranten Transformation der HTML-Struktur in einen Haskell-Datentyp. Da die vorhandenen HTML-Dateien, einen XML-Aufbau beinhalten, knnen fr die Verfahrenssuche auch XML-Bibliotheken betrachtet werden. Es muss die berlegung angestellt werden, ob ein fertiges Verfahren verwendet werden kann oder ob ein Verfahren in Eigenproduktion entwickelt werden muss. Bei den fertigen Verfahren, werden die bekanntesten Verfahren in Haskell, um XML und HTML-Datenstrukturen zu verarbeiten, betrachtet, diese sind: blaze-html, HaXml, xhtml und TagSoup. Im Folgenden werden die Eigenschaften der verschiedenen Verfahren betrachtet und entschieden, welche von ihnen fr das Projekt geeignet sind. Fr eine Eigenproduktion wird ein Parser-Verfahren unter der Zuhilfenahme von Parsec verwendet.

3.2.1 blaze-html
Die blaze-html Bibliothek ist eine HTML-Bibliothek fr Haskell. Diese ermglicht es HTML 4 und HTML 5 konforme Strukturen zu verarbeiten.1 Durch das blaze-fromhtml-Projekt, das auf der blaze-html-Bibliothek basiert, ist es mglich eine Umwandlung des vorhandenen HTML-Stundenplans durchzufhren. Aus dem QuellCode des blaze-from-html-Projektes ist zu entnehmen, dass das TagSoup-Projekt eingebunden wird. Im Rahmen der Bachelorarbeit war es aus Zeitgrnden nicht mglich, den Quellcode so zu analysieren, dass nachgewiesen werden kann, dass die HTML-Transformation mit dem TagSoup-Projekt umgesetzt wird oder ob es nur
1

Vgl. Van der Jeugt und Meier

Seite 11

KAPITEL 3. VORBETRACHTUNG

als Hilfsmittel verwendet wird. Die Transformation kann nur umgesetzt werden, da blaze-from-html die Mglichkeit bietet sehr tolerant mit den Fehlern der HTMLSeite umzugehen. Dadurch ist es mglich die HTML-Struktur in eine Haskell-Form umzuwandeln. Da die Mglichkeit der Weiterverarbeitung dieser Haskell-Daten jedoch im Rahmen der Arbeit zu umfangreich ist, wird dieses Verfahren nicht weiter betrachtet.

3.2.2 Parsec
Parsec2 bietet die Mglichkeit ber Parser-Kombinatoren eigene Parser zu entwickeln. Dadurch ist es mglich, Parser zu entwerfen, durch die ein HTML-Syntax verarbeitet werden kann. Bei der Test-Implementierung stellte sich heraus, dass der Aufwand um eine komplette HTML-Datei zu parsen, den Rahmen der Arbeit bersteigt und das Ziel verfehlt.

3.2.3 HaXml
HaXml is a collection of many utilities for parsing, ltering, transforming, and generating XML documents using Haskell. 3 HaXml liefert umfangreiche Funktionalitt um auch HTML-Dateien zu parsen. Bei einer Test-Implementierung zeigte sich jedoch, dass beim Parsen des Stundenplans ein "Lexical error"verursacht wird, wodurch eine Weiterarbeit mit diesem Verfahren nicht mglich ist. Das Problem ist beim Test mit dem Stundenplan des Informatik Studiengangs des sechsten Semesters aufgetreten http://sund.de/steffen/plan/s_bai6.html. Der Fehler ist in Zeile 6 und Spalte 108 mit der Zeichenfolge type=text/css aufgetreten. Das Problem ist, dass keine Verarbeitung stattnden kann, da keine Anfhrungsstriche um den Wert vom type sind. Daher versucht HaXml den / zu interpretieren.

2 3

Vgl. Verfasser, Parsec Wallace

Seite 12

KAPITEL 3. VORBETRACHTUNG

3.2.4 xhtml
Die xhtml-Bibliothek verarbeitet den XHTML 1.0 Standard.4 Da die StundenplanSeite HTML 4.01 Transitional ist, kann diese Bibliothek nicht verwendet werden.

3.2.5 TagSoup
TagSoup ist eine Bibliothek zum Parsen von HTML-/XML-Datenstrukturen.5 Die TagSoup-Bibliothek kann die vorliegende HTML-Datenstruktur, durch den Toleranten Parser, fehlerfrei in eine Haskell-TagSoup-Datenstruktur transformieren. Der Aufbau dieser Datenstruktur ist im Listing 3.5 dargestellt.
1

[ TagOpen "HTML" [ ] , TagText " \ r \n " , TagOpen "BODY" [ ( "BGCOLOR" , "#FFFFFF" ) , ( " s t y l e " , " background image : u r l ( b i l d e r / l o g o . jpg ) ; backgroundattachment : f i x e d ; backgroundr e p e a t : nor e p e a t ; backgroundp o s i t i o n : c e n t e r 50% " ) ] "

, TagClose "BODY" , TagClose "HTML" ] Listing 3.5: TagSoup Beispiel

4 5

Vgl. Bringert Vgl. Mitchell, tagsoup

Seite 13

KAPITEL 3. VORBETRACHTUNG

In Listing 3.6 ist der Aufbau des Datentypes abgebildet.6

1

data T name s t r i n g = Open (Name name ) [ T name s t r i n g ] | C l o s e (Name name ) | Text s t r i n g | Comment String | S p e c i a l (Name name ) String | P r o c e s s i n g (Name name ) (T name s t r i n g ) | Warning String Listing 3.6: TagSoup Datentyp

In der nachfolgenden Tabelle 3.1 bezieht sich die Ausgabe auf die Datenstruktur, die am ende von dem Verfahren generiert wird und dabei in Bezug auf die Verwendbarkeit dieser. Die Felder in denen k.A. steht, bedeuten, dass entweder keine Informationen dazu gefunden wurden oder das frhere Kriterien dazu gefhrt haben, dass dieser Punkt nicht nher betrachtet wurde. Die Ziele, die die Verfahren erfllen sollten, waren: Verarbeiten der HTML-Struktur Vollstndige Transformation der HTML-Struktur Korrekte Transformation des ttribut-value Problems Verarbeiten mit geringem Aufwand des Ausgabe-Formats Aufgrund der Tabelle kann erkannt werden, dass das TagSoup Verfahren am geeignetsten ist, da es die gestellten Ziele erfllt. Verfahren blaze-html HaXml xhtml TagSoup HTML ja ja ja ja Transformation ja nein nein ja attribut=value Ausgabe-Format ja nein nein ja nein k.A. k.A. ja

Tabelle 3.1: Tabelle zur Verfahrensauswertung

Vgl. Mitchell, tagsoupTag

Seite 14

KAPITEL 3. VORBETRACHTUNG

3.3 Beschreibung des verwendeten Verfahrens

Anhand der oben analysierten Verfahren und der daraus ermittelten Ergebnisse, ist die Entscheidung fr das zu verwendende Verfahren auf TagSoup gefallen. Im Listing 3.5 ist ein Beispiel dargestellt, wie die TagSoup-Datenstruktur aufgebaut ist. Die Struktur, die von dem TagSoup-Modul erzeugt wird, ist eine ache Hierarchie. Das bedeutet, dass anhand der Liste von HTML-Tags nicht direkt entschieden werden kann, wann ein HTML-Tag beginnt und wann dieser endet und welche Unterelemente ein HTML-Tag besitzt. Des Weiteren muss die vom TagSoup generierte Datenstruktur verarbeitet werden. Zur Transformation der von TagSoup generierte Datenstruktur wird ein Zustandsautomat verwendet. Fr solch einen Zustandsautomat wurden in dieser Bachelorarbeit zwei Varianten betrachtet. Die erste und einfachste Mglichkeit ist es, in Eigenentwicklung einen Zustandsautomaten zu implementieren, der anhand der nenden und schlieenden HTML-Tags eine Hierarchie-Struktur aufbaut. Durch diese kann eine genaue Zuordnung der gesuchten HTML-Tags geschehen. Der Nachteil dieser Lsung ist, dass das Warten des Zustandsautomaten und die Anpassung bei nderungen der Stundenplan-Darstellung aufwndig ist. Die zweite Variante ist einen Zustandsautomaten generieren zu lassen. Dies kann mit einem Verfahren geschehen, das regulre Ausdrcke nutzt. Dadurch wird eine abstraktere Beschreibung der Transformation mglich. Die Arbeitsweise, die beide Varianten verwenden, nennt sich lexikalische Analyse. Die lexikalische Analyse zerteilt den eingelesenen Quelltext in zusammengehrende Token verschiedener Klassen, zum Beispiel Schlsselwrter, Bezeichner, Zahlen und Operatoren. 7 Eine lexikalische Analyse verarbeitet eine Zeichenkette, in dem sie diese von links nach rechts liest und die Zeichen in Symbole (sogenannte Tokens) umformt.8 In der deutschen Sprache ist beispielsweise die lexikalische Struktur, also die verwendbaren Wrter, durch den Duden speziziert. 9

7 8 9

Verfasser, Lexikalische Analyse Vgl. Schmitt, S. 2 Schmitt, S. 2

Seite 15

KAPITEL 3. VORBETRACHTUNG

Da die lexikalische Analyse einen Eingabetext nach bestimmten Textmustern abtastet, wird sie oft auch als Scanner bezeichnet. 10 Um eine Technik zum Entwerfen von Scannern zu entwicklen, ist es notwendig, das Muster genau zu denieren, das die Menge der Lexeme zu einem Symbol beschreibt. Eine gebruchliche Notation zum Spezizieren von Mustern sind regulre Ausdrcke. Regulre Ausdrcke beschreiben die jedem Muster entsprechende Menge von Zeichenketten (Strings) im Eingabetext. 11 Der Vorteil, der bei der Nutzung von regulren Ausdrcken mit dem Stundenplan im Vordergrund steht, ist, dass bei nderungen eine rasche Anpassung vorgenommen werden kann, da nur der regulre Ausdruck angepasst werden muss. Dieser ist einfach verstndlich im Gegensatz zu dem selbst entwickelten Zustandsautomaten. Somit ergibt sich eine bessere Wartbarkeit.12 Im Rahmen der Bachelorarbeit ist die Entscheidung zur Problemlsung auf die Eigenentwicklung eines Zustandsautomaten gefallen. Der Grund, der fr eine Eigenentwicklung des Zustandsautomaten spricht ist, dass er einfach umzusetzen ist und fr die momentane Verwendung der Einsatz ber regulre Ausdrcke im Vergleich dazu unverhltnismig wre. Des Weiteren ist ein auf das Problem angepasster Zustandsautomat ezienter als ein durch regulre Ausdrcke generierter. Da der Teil des Projektes, der sich mit der Transformation der HTML-Struktur beschftigt, nur als bergangslsung verwendet wird, bis ein weiterer Teil des Spirit-Projektes abgeschlossen wird, ist keine lange Laufzeit dieses Modules zu erwarten. Daher wird nicht erwartet, dass der Aufbau der HTML-Seite bis zum Start des Spirit Teilprojektes, das die Generierung des neuen Stundenplans bernimmt, verndert wird. Das wird dadurch untersttzt, dass die Generierung der Stundenplan-HTML-Datei statisch ist und voraussichtlich nicht verndert wird. Damit ist der Einsatz eines Zustandsautomaten gerechtfertigt.

10 11 12

Herold, S. 21 Schmitt, S. 41 Vgl. Schmitt, S. 42

Seite 16

4 Transformation der HTML-Stundenplandaten

Bei der Transformation der HTML-Stundenplandaten geht es darum, den HTMLStundenplan in das Programm einzulesen, sodass er im Zustandsautomaten verarbeitet und in die Zwischenstruktur transformiert werden kann. Dann kann die interne Datenstruktur aus der Zwischenstruktur erzeugt werden.

4.1 Entwicklung einer Zwischenstruktur

Damit die HTML-Stundenplan-Daten in Haskell gespeichert werden knnen, wird eine Datenstruktur bentigt. Diese Datenstruktur wird im Folgenden immer Zwischenstruktur genannt. Die Grnde, die zur Verwendung einer Zwischenstruktur gefhrt haben, werden im Laufe der Arbeit errtert. Der Aufbau der Zwischenstruktur ist einfach gehalten. Sie besteht in der ersten Ebene aus einer Liste von Tupeln. Listen beinhalten eine beliebige Anzahl von Elementen gleichen Typs und Tupel haben immer eine festgelegte Anzahl von Elementen, bei denen der Typ unterschiedlich seien kann. Das erste Element des Tupels ist der Tag, an dem die Veranstaltungen stattnden, zum Beispiel: Montag, Dienstag, Mittwoch, Donnerstag oder Freitag. Bei dem zweiten Element handelt es sich um eine Liste von Tupeln. In diesem Tupel stellt das erste Element die Uhrzeit dar, zu der die Veranstaltungen stattnden. Der zweite Teil des Tupels ist eine Liste von Listen mit Strings. Diese Ebene stellt die einzelnen Veranstaltungen in einem Slot dar. Die Listen von Strings bilden die verschiedenen Stundenplan-Informationen ab. Da die Elementeanzahl der Stundenplan-Informationen unterschiedlich ist, wurde in diesem Fall eine Liste von Strings verwendet, da Elementeanzahlen bei diesen verschieden sein knnen, anders als bei Tupeln. Der Aufbau der Zwischenstruktur ist in Listing 4.1 im Haskell-Syntax

17

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

dargestellt. Zeile 2 soll dem Leser nur exemplarisch verdeutlichen, welche Werte an den einzelnen Stellen zu erwarten sind und ist daher nicht in der prototypischen Implementierung enthalten.
1

[ ( String , [ ( String , [ [ String ] ] ) ] ) ] [ ( TagDerWoche , [ ( U h r z e i t , [ L i s t e V o n V e r a n s t a l t u n g e n ] ) ] ) ] Listing 4.1: Aufbau der Zwischenstruktur

Da nun eine Datenstruktur vorhanden ist, in der die Stundenplandaten gespeichert werden knnen, ohne ihren Zusammenhang zu verlieren, kann nun mit der Transformation begonnen werden.

4.2 Transformation der HTML-Struktur

Nach dem die Wahl des Verfahrens zur Transformation der HTML-Struktur auf das TagSoup-Modul gefallen ist, wird eine Funktionalitt bentigt, die die TagSoupStruktur verarbeiten und in die Zwischenstruktur speichern kann. Im Listing 3.5 ist der Aufbau der TagSoup-Struktur dargestellt. Der Aufbau der Struktur ist wie folgt zu verstehen: Ein nendes HTML-Tag, zum Beispiel <html>, wird dadurch abgebildet, dass der TagOpen-Konstruktor erzeugt wird. Dieser hat zwei Attribute. Das erste enthlt den Namen des zu nenden HTML-Tags, das zweite enthlt eine Liste aller Attribute, die das HTML-Tag bentigt. Diese sind durch Kommas getrennt. In Zeile drei des Listings 3.5 ist ein Beispiel dafr dargestellt. Fr die Verarbeitung der TagSoup-Datenstruktur wird ein Zustandsautomat eingesetzt. Mit diesem ist es mglich, die relevanten Stundenplan-Daten zu nden und in die Zwischenstruktur zu speichern. In Abbildung 4.1 ist der Ablauf der Transformation mit seinen einzelnen Datenstrukturen dargestellt.

Seite 18

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

Abbildung 4.1: Transformationsschritte. Quelle: Eigene Darstellung.

4.3 Der Zustandsautomat

Damit der HTML-Stundenplan in die Zwischenstruktur transformiert werden kann, sind zwei Zustandsautomaten ntig. Der erste ist in Abbildung 4.2 dargestellt. Dieser Automat ltert die Tage, die im HTML-Stundenplan im Kopf der Tabelle abgebildet werden. Anschlieend wird der noch nicht verarbeitete Teil der Stundenplantabelle an den zweiten Zustandsautomaten weitergegeben, der in Abbildung 4.3 dargestellt ist.

Seite 19

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

Abbildung 4.2: Zustnde fr den Tabellen Kopf. Quelle: Eigene Darstellung.

Abbildung 4.3: Zustnde fr den Tabellen Krper. Quelle: Eigene Darstellung.

Der Zustandsautomat zwei hat sechs Zustnde. Im Zustand searchTR wird fr eine Zustandsnderung in den Zustand SearchTD1 ein nendes TR-Tag erwartet. Des Weiteren wird im Zustand SearchTD1 fr eine Zustandsnderung in den darauf folgenden Zustand SearchText1TD ein TD-Tag erwartet. Ein schlieendes TR-Tag fhrt zum Ende dieses Zustands. Das bedeutet einen Wechsel in den Zustand searchTR. Im Zustand SearchText1TD fhrt ein nendes TABLE-Tag zum Wechsel in den readSlots Zustand. Ein schlieendes

Seite 20

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

TD-Tag in diesem Zustand fhrt zum Ende dieses Zustandes und zum Wechsel in den Zustand SearchTD1, da dies bedeutet, dass das Zeilenende erreicht ist. Im Zustand readSlots wird fr eine Zustandsnderung in den Zustand SearchSlotTD ein nendes TR-Tag erwartet. Bei einem schlieenden TABLE-Tag ndet eine Zustandsnderung in den SearchText1TD-Zustand statt. Im Zustand SearchSlotTD wird fr eine Zustandsnderung in den Zustand SearchSlotText ein nendes TDTag erwartet. Bei einem schlieenden TR-tag wird in den Zustand readSlots zurck gewechselt. Im Zustand SearchSlotText fhrt das Auftreten eines TagText-Tags zu einer Speicherung der darin enthaltenen Daten. Bei einem schlieenden TD-Tag wird ein Zustandswechsel in den Zustand SearchSlotTD ausgelst. Wenn der Zustandsautomat beendet wird, liefert er die Zwischenstruktur als Ergebnis. In den Anhngen A.1 und A.2 sind zur Verdeutlichung der Funktionsweise des Zustandsautomaten Zustandstabellen abgebildet.

4.4 Implementierung des Zustandsautomaten

Im Projekt wurden zwei verschiedene Anstze der Implementierung von Zustandsautomaten verfolgt. Der Erste ist die Implementierung der Zustnde als Funktionen. Das bedeutet, dass jeder Zustand als eine Funktion abgebildet wird. Diese Implementierung ist sehr wartungsintensiv. Da bei jeder nderung der Zustnde die Funktionen angepasst oder hinzugefgt werden mssen. Auf Grundlage dieser Erfahrung wurde ein zweiter Ansatz zur Implementierung verfolgt. In diesem werden die Zustnde ber eine Zustandstabelle abgebildet. Dann wird ein Algorithmus bentigt, der anhand der Eingabe und der Zustandstabelle Folgezustnde ermittelt. Dadurch ergibt sich die Mglichkeit, durch einfaches ndern der Zustandstabelle eine Verhaltensbeeinussung des Automaten zu verursachen. Im Anhang A.1 ist ein Ausschnitt des tabellengesteuerten Automaten dargestellt.1

Die vollstndige Implementierung bendet sich in der Quellcode-Datei src/HtmlToListV2.hs. Diese ist im Projekt-Verzeichnis auf CD oder online unter https://github.com/spirit-fhs/ timetable2db einzusehen.

Seite 21

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

4.5 Entwicklung der internen Datenstruktur

Die interne Datenstruktur stellt die zentrale Schnittstelle dar. Sie wird verwendet, um die Stundenplan-Informationen so zu speichern, dass sie schnell verarbeitet werden knnen. Des Weiteren soll sie dem neuen Stundenplan-Generator als Einstieg dienen, damit dieser die Export- und Transfer- Funktionen nutzen kann. Die interne Datenstruktur ist in der prototypischen Implementierung als Datentyp Lecture dargestellt und wie folgt aufgebaut: Es gibt einen Speicherplatz fr den Tag der Woche, dieser ist durch day abgebildet. Des Weiteren existiert ein Typ TimeSlot. Dieser ist durch timeSlot dargestellt und beinhaltet eine Datenstruktur zum Speichern der Start- und Ende-Informationen, die aus dem HTML-Stundenplan entnommen wurden. Start und Ende einer Veranstaltung sind immer durch einen Zeitstempel dargestellt. Dieser wird wie folgt dargestellt: HH.MM-HH.MM. Der Vorlesungstyp ist durch vtype vom Typ String, in die Datenstruktur aufgenommen wurden. Der Name der Veranstaltung, zum Beispiel Analysis, ist durch vname vom Typ String, in der Datenstruktur vertreten. Als nchstes folgt der Ort der Veranstaltung, zum Beispiel B102. Dieser ist durch location vom Typ Location dargestellt. Location ist ein Typ, der den Ort in Gebude und Raum trennt. Das Gebude ist durch building und der Raum durch room in die Datenstruktur aufgenommen wurden. Das Wochen-Intervall in dem die Veranstaltungen stattnden ist in week, vom Typ String, gespeichert. Dieses Wochen-Intervall kann zum Beispiel wchentlich oder alle zwei Wochen stattnden. Falls vorhanden, ist die Gruppeneinteilung der Veranstaltung in group zu nden, die vom Typ String ist. Zum Schluss muss noch der Dozent gespeichert werden, dies geschieht in lecturer. Dieser ist vom Typ String. In Listing 4.2 ist die implementierte Struktur der prototypischen Umsetzung dargestellt.
1

data TimeStamp = TimeStamp

{ hour

: : String

, minute : : String } data TimeSlot = TimeSlot { tstart , tend } data L o c a t i o n = Location { b u i l d i n g : : String , room : : String : : TimeStamp : : TimeStamp

Seite 22

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

} data L e c t u r e = Lecture { day : : String

10

11

, t i m e S l o t : : TimeSlot , vtype , vname : : String : : String

12

13

14

, l o c a t i o n : : Location , week , group : : String : : String

15

16

17

, l e c t u r e r : : String } | EmptyLecture type TimeTable = [ Lecture ] Listing 4.2: Aufbau der internen Datenstruktur

18

19

20

Im Listing 4.2 ist in Zeile 20 die Denition fr den Stundenplan-Datentypen zu erkennen. Dieser stellt sich durch eine Liste von Lecture dar und wird als TimeTable bezeichnet. Der Zeile 19 kann entnommen werden, dass der Datentype Lecture auch den Wert EmptyLecture annehmen kann. Dieser Wert wird bentigt, da fr eine Weiterentwicklung ein Vergleich mit dem Lecture Datentype mglich sein muss. Ein Anwendungsbeispiel wre, wenn der RESTful-Service keinen Stundenplan zurckliefert.

4.6 Zwischenstruktur in interne Datenstruktur transformieren

Wenn nun der Automat die Transformation der HTML-Struktur in die Zwischenstruktur abgeschlossen hat, kann diese in die interne Datenstruktur umgewandelt werden. Die interne Datenstruktur wird bentigt, da diese das Schnittstellen-Format darstellen soll, das spter von dem neuen Stundenplan-Generierungsprogramm genutzt werden soll. Im Listing 4.3 wird ein Beispiel fr den Aufbau der Zwischenstruktur dargestellt.
1

[ ( " 08.15 09.45 " , [ ( " Montag " , [ ] ) ,( " Dienstag " , [ ] )

Seite 23

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

, ( " Mittwoch " , [ [ " " , " Uebung " , "SWEProg V3" , "PC2 " , " u " , " 1 " , " Braun " ] , [ " " , " Uebung " , "SWEProg V3" , "PC2 " , " g " , " 2 " , " Braun " ] ] ) , ( " Donnerstag " , [ [ " " , " V o r l e s u n g " , "SWEProg V3" , " F004 w " , " Braun " ] ] ) ,( " Freitag " , [ ] ) ] ) ] Listing 4.3: Ausschnitt aus der Zwischenstruktur

Da bei der Zerlegung einer Veranstaltung nicht gesagt werden kann, an welcher Stelle in der HTML-Struktur sich ein Element bendet, muss eine Zwischenstruktur eingefhrt werden. Im Listing 4.4 ist ein Beispiel dargestellt.
1

[ " " , " V o r l e s u n g " , "SWEProg V2" , " H0216 w " , " Recknagel " ] [ " " , " Uebung " , "DBS V1" , "WKST " , " g " , " 1 " , " K n o l l e " ] Listing 4.4: Grund fr eine Zwischenstruktur

In diesem Beispiel ist zu sehen, dass eine Gruppeneinteilung die Anzahl der Elemente in der Liste verndert. Es kann nicht davon ausgegangen werden, dass immer das selbe Format auftritt, sobald eine Vorlesung oder bung vorliegt. Das bedeutet, dass die Reihenfolge der Elemente, wie im Listing 4.5 exemplarisch fr eine Vorlesung zu sehen ist, nicht bei jeder Vorlesung oder bung gleich ist. Folgendes Problem muss bedacht werden: Vorlesungen knnen nicht nur wchentlich, sondern auch alle zwei Wochen stattnden. Die Darstellung einer solchen Vorlesung ist in Listing 4.5 abgebildet.
1

[ " " , " V o r l e s u n g " , "Komm V1/V2" , " H0002 " , " u " , " " , " Dimanski " ] Listing 4.5: Zwischenstruktur Vorlesung u

Des Weiteren kann in Listing 4.4 festgestellt werden, dass es unterschiedliche Darstellungsarten fr die Wocheneinteilung gibt. In Zeile 1 kann man erkennen, dass die Veranstaltung eine Vorlesung ist und dass diese wchentlich statt ndet. Es ist auerdem zu sehen, dass die Kennzeichnung, dass die Vorlesung wchentlich stattndet, bei der Rauminformation enthalten ist. In Zeile 2 wird dieser Sachverhalt anders dargestellt. Da die aufgezeigte bung alle zwei Wochen stattndet, ist die Information dafr, also g in einem eigenem Element hinterlegt und nicht wie in Zeile 1 bei der Raum Information enthalten. Das sind Grnde, warum sich der Autor der Bachelorarbeit gegen eine direkte Transformation der TagSoup-Datenstruktur

Seite 24

KAPITEL 4. TRANSFORMATION DER HTML-STUNDENPLANDATEN

in die interne Datenstruktur entschieden hat. Der Vorteil ist, dass nun an einer zentralen Stelle im Programm eine Beschreibung gemacht werden kann. In dieser Beschreibung mssen alle Sonderflle der Elemente-Reihenfolge aufgenommen werden. Dieser Sachverhalt ist zugleich ein Nachteil, da er die Pege des Programms erhht, denn jeder mgliche Aufbau einer Veranstaltung muss an dieser Stelle eingetragen sein. Anderenfalls wird der Stundenplan nicht transformiert.

Seite 25

5 Erweiterung und Speicherung der internen Datenstruktur

In diesem Kapitel wird die Erweiterung der internen Datenstruktur behandelt. Es wird gezeigt, wie die erweiterte Struktur aussehen soll. Weiterhin soll dargelegt werden, wie die Speicherung der Datenstruktur durchgefhrt wird.

5.1 Erweiterung der internen Datenstruktur

Die interne Datenstruktur muss nun zur weiteren Verarbeitung im RESTful Service erweitert werden. Es mssen verschiedene Informationen zu den Daten des vorhergehenden Stundenplans hinzugefgt werden, damit diese in die Datenbank eingefgt werden knnen. In Abbildung 5.1 ist dargestellt, wie die Zusammensetzung der erweiterten internen Datenstruktur aufgebaut ist.

5.1.1 Ausung der Dozenten-Bezeichnung

Ein wichtiger Punkt ist die Ausung der Dozenten-Bezeichnung. Bei der DozentenBezeichnung handelt es sich um einen Pseudonamen, der entweder dem Namen des Dozenten entspricht oder einer Kombination aus mehreren Namen. Die Kombination kommt vor, wenn mehrere Dozenten fr eine Vorlesung eingeteilt sind. Des Weiteren ist, laut der Aussage von Herrn Gerd Recknagel, Dozent der Fachhochschule Schmalkalden, dem Verantwortlichen fr die Stundenplanung der Fakultt Informatik, der Speicherplatz fr den Dozentennamen auf maximal 10 Zeichen beschrnkt. Dadurch werden zu lange Namen abgeschnitten. Dieser Sachverhalt muss bei der Erstellung der Software bedacht werden. Die Datenbank bentigt die FhsID des Dozenten als eindeutige Zuordnung. Daher muss ein Datenbestand generiert werden, der von einem Pseudonamen auf die FhsID schlieen kann. Als Datenbestand liegen zwei

26

KAPITEL 5. ERWEITERUNG UND SPEICHERUNG DER INTERNEN DATENSTRUKTUR

Abbildung 5.1: Zusammensetzung der erweiterten internen Datenstruktur. Quelle: Eigene Darstellung.

Dateien vor. In der einen sind alle Dozenten mit einer eindeutigen FhsID enthalten. Die Datenstruktur dieses Datenbestandes ist in JSON abgebildet und stammt aus einer nicht entlichen Quelle. Deshalb musste auf eine lokale Datei zurck gegriffen werden. Die zweite Datei beinhaltet die bisher bekannten Namenskombinationen der Dozenten, damit eine Zuordnung auch dann erstellt werden kann, wenn mehr als ein Dozent eine Veranstaltung hlt. Damit ist es nun mglich die vorhandenen Pseudonamen in existierende Namen zu berfhren und somit die FhsID zu jedem Dozenten zu bestimmen. Diese wird bentigt um die Stundenplan-Daten in die Datenbank einzufgen. In Abbildung 5.2 ist die Zusammenfhrung der verschiedenen Datenbestnde dargestellt.

Seite 27

KAPITEL 5. ERWEITERUNG UND SPEICHERUNG DER INTERNEN DATENSTRUKTUR

Abbildung 5.2: Dozenten-Datenbestand. Quelle: Eigene Darstellung.

5.1.2 Beginn und Ende einer Veranstaltung

Eine Veranstaltung hat ein Beginn und ein Ende. Diese sind in der alten StundenplanVersion durch Zeitangaben abgebildet. Damit die Informationen in das DatenbankSchema integriert werden knnen, wird zu den Zeitangaben noch ein Datumsbereich bentigt. Der Datumsbereich soll angeben, an welchem Datum eine Veranstaltung beginnt und wann sie endet. Diese Angabe wird bentigt, da eine Veranstaltung zum Beispiel ber ein ganzes Semester gehalten werden kann oder als Blockveranstaltung an einem Wochenende. Diese Informationen knnen nicht aus dem alten Stundenplan gewonnen werden und mssen durch Zusatzinformationen ergnzt werden. Zur Verdeutlichung dient das folgende Beispiel 5.1.
1

1 1 . 0 0 1 2 . 3 0 SWE V3 V o r l e s u n g u F0004 0 7 . 0 4 . 2 0 1 1 0 7 . 0 7 . 2 0 1 1 Listing 5.1: Stundenplan Beispiel mit Zusatzinformationen

Anhand dieser Datumsinformationen und der Information, dass die Veranstaltung in einer geraden oder ungeraden Woche stattndet, knnen alle Einzel-Termine fr die Veranstaltung generiert werden. Da eine weitere Bearbeitung des Teilprojektes fr diese Bachelorarbeit zu umfangreich wre, wird an diesem Punkt aufgehrt.

5.1.3 Ablaufdatum der Veranstaltung

Da die Datenbank so geplant ist, dass keine Daten gelscht werden mssen, bentigen die Veranstaltungen ein Ablaufdatum. Dieses ermglicht es, dass die Veranstaltung ab einem bestimmten Datum nicht mehr vom RESTful Service angeboten

Seite 28

KAPITEL 5. ERWEITERUNG UND SPEICHERUNG DER INTERNEN DATENSTRUKTUR

wird. Um den Zweck des Ablaufdatums zu verdeutlichen, dient das folgende Beispiel: Wenn eine Veranstaltung vom 01.03.2011 bis zum 30.06.2011 geplant ist, diese aber aus bestimmten Grnden am 20.05.2011 nicht mehr vom RESTful Service angeboten werden soll, dann wird das Ablaufdatum auf den 20.05.2011 gesetzt. Wenn nun die Stundenplan-Daten am 22.05.2011 vom RESTful Service angefordert werden, dann wird diese Veranstaltung nicht in der Ergebnismenge enthalten sein.

5.1.4 Studiengangname und classID

In der Datenbank wird eine Verwaltung des Studiengangs ber classIDs realisiert. Da zum aktuellen Zeitpunkt nicht abzusehen ist, ob es im RESTful Service eine Funktion geben wird, mit der nach dieser classID gefragt werden kann, muss diese dem Programm mitgegeben werden. Dies geschieht ber einen Parameter beim Programmstart. Ein weiterer Ansatz ist einen Datenbestand anzulegen, in dem eine Zuordnung zwischen der classID und dem Studiengang abgebildet wird.

5.2 Exportieren der interne Datenstruktur

Die interne Datenstruktur soll in ein verarbeitbares Dateiformat exportiert werden. Hierbei kann jedes beliebige Dateiformat gewhlt werden. Da als Kommunikation zum RESTful Service eine JSON-Datenstruktur verwendet wurde, wird an dieser Stelle auch JSON verwendet. In Haskell gibt es dafr verschiedene Bibliotheken, die Verbreitetste ist Aeson. Sie ermglicht die Transformation einer HaskellDatenstruktur in das JSON-Format. Nun knnen die JSON-Daten in eine Datei exportiert werden, damit diese Dateien anderen Anwendungen bereitstehen oder zur Archivierung zur Verfgung stehen.

Seite 29

KAPITEL 5. ERWEITERUNG UND SPEICHERUNG DER INTERNEN DATENSTRUKTUR

Abbildung 5.3: Kommunikation mit RESTful Service. Quelle: Eigene Darstellung.

5.3 bertragung der JSON-Daten zum RESTful Service

Die bertragung der JSON-Daten erfolgt ber das Hypertext Transfer Protocol Secure (HTTPS). HTTPS ist eine Kombination aus dem HTTP und SSL/TLS Protokoll.1 In Abbildung 5.3 ist eine lesende Kommunikation abgebildet. Um in Haskell eine HTTPS-Verbindung aufzubauen, werden verschiedene Bibliotheken bentigt. In der Bachelorarbeit wurde die HTTP- und die TLS-Bibliothek verwendet. Mit diesen kann eine Verbindung zum RESTful Service aufgebaut werden. Bei dem RESTful Service muss beachtet werden, dass in der HTTPS-Anfrage im Header die Accept Option mit application/json gesetzt werden muss. Damit wird dem RESTful Service mitgeteilt, dass als Antwort JSON-Daten akzeptiert werden. Wenn nur die Stundenplan-Daten vom RESTful Service abgefragt werden sollen, dann reichen diese Option und die Methode GET fr eine Abfrage aus. Wenn die StundenplanDaten zum RESTful Service bertragen werden sollen, muss eine weitere Option im

Vgl. Verfasser, HTTPS

Seite 30

KAPITEL 5. ERWEITERUNG UND SPEICHERUNG DER INTERNEN DATENSTRUKTUR

Header gesetzt werden. Diese Option ist Content-Type mit dem Wert application/json. Hierbei muss des Weiteren beachtet werden, dass als Methode PUT verwendet wird.2

Vgl. Ldicke

Seite 31

6 Resmee
Zusammenfassend lsst sich sagen, dass es einen Wendepunkt bei der Erarbeitung der Bachelorarbeit gab. Dieser betrit das blaze-html-Projekt. Bei der Planung der Bachelorarbeit wurde blaze-html als Verfahren zur Transformation der HTMLDaten favorisiert. Im Laufe der Bachelorarbeit stellte sich heraus, dass die Verwendung dieses Verfahrens zu aufwendig ist. Dadurch musste nach einem anderen Verfahren gesucht werden. Um zuknftig ein eektives und exibles Werkzeug zu schaen, knnte dieses Projekt durch die angesprochene lexikalische Analyse erweitert werden. Dann knnte das Projekt so erweitert werden, dass auf Vernderungen der HTML-Seiten besser reagiert werden kann als bei der Nutzung eines Zustandsautomaten. Die Ziele, die diese Bachelorarbeit verfolgt hat, sind: die Daten aus dem alten Stundenplanungstool exportieren eine Schnittstelle fr das alte und neue Stundenplanungstool anbieten die Stundenplan-Daten aufbereiten und exportieren Der Export der Stundenplan-Daten musste auf den Export der JSON-Daten eingeschrnkt werden. Grund dafr ist, dass der RESTful Service nicht im bentigten Umfang zur Verfgung stand. Trotzdem wurde eine prototypische Implementierung des RESTful Service zu Testzwecken durchgefhrt. Die Umsetzung betrit den lesenden Zugri auf den RESTful Service. Das Ziel, das die Schnittstelle fr das neue Stundenplanungstool umsetzen sollte, konnte nicht vollstndig umgesetzt werden. Grund dafr ist, dass die Daten die von dem neuen Stundenplanungstool geliefert werden, noch nicht deniert sind. Deswegen ist die Entscheidung auf die intere Datenstruktur als Schnittstelle gefallen. Das bedeutet aber auch, dass nicht mehr Informationen eingepegt werden knnen als vorher. An dieser Stelle muss in einer spteren Arbeit angesetzt werden. Alle in der Arbeit erreichten Programmierergebnisse, sind in einem ffentlichen GIT Repository unter https://github.com/spirit-fhs/timetable2db

32

KAPITEL 6. RESMEE

einzusehen. Diese beinhalten unter anderem die prototypische Implementierung des Migrate Programms.

Seite 33

A Anhang
A.1 Implementierung des Zustandsautomaten
1

palTab : : [ ( ( String palTab = [ ( ( "TR" , ( ( "TH" , ( ( "TD" , ( ( " /TR"

, Integer ) , ( Integer , String ) ) ] , 0 ) , (1 , " " ) ) , 1 ) , (2 , " " ) ) , 1 ) , (3 , " " ) ) , 1 ) , (0 , " " ) )

, ( ( "TEXT! " , 2 ) , ( 2 , "PUSH" ) ) , ( ( " /TH" , 2 ) , (1 , " " ) )

, ( ( "TEXT! " , 3 ) , ( 3 , "PUSH" ) ) , ( ( "TABLE" , 3 ) , ( 4 , " " ) ) , ( ( " /TD" , 3 ) , (1 , " " ) )

10

11

, ( ( " /TABLE" , 4 ) , ( 3 , " " ) ) , ( ( "TR" , ( ( "TD" , ( ( " /TR" , 4 ) , (5 , " " ) ) , 5 ) , (6 , " " ) ) , 5 ) , (4 , " " ) )

12

13

14

15

, ( ( "TEXT! " , 6 ) , ( 6 , "PUSH" ) ) , ( ( "IMAG! " , 6 ) , ( 6 , "PUSH" ) ) , ( ( " /TD" ] intKA : : Tag [ Char ] > ( String , String ) intKA i n p u t = case i n p u t of TagOpen TagOpen TagOpen TagOpen "TR" "TD" "TH" _ > ( "TR" , [ ] ) _ > ( "TD" , [ ] ) _ > ( "TH" , [ ] ) , 6 ) , (5 , " " ) )

16

17

18

19

20

21

22

23

24

25

"TABLE" _ > ( "TABLE" , [ ] )

34

26

27

TagOpen

" img " (_ : ( " s r c " , " b i l d e r / monitor . g i f " ) : _) > ( "IMAG! " , " Uebung " )

28

29

TagOpen

" img " (_ : ( " s r c " , " b i l d e r / buch . g i f " ) > ( "IMAG! " , " V o r l e s u n g " )

: _)

30

31

32

TagClose t a g TagText _

> ( ( / : t a g ) , [ ] ) v a l u e > ( "TEXT! " , v a l u e ) > ( [ ] , [])

33

34

35

c h e c k S t a t e : : [ Tag [ Char ] ] > Integer > [ ( ( String , Integer ) , ( Integer , String ) ) ] > [ String ] > [ [ String ] ] > [ [ [ String ] ] ] > [ [ [ String ] ] ] checkState [ ] _ _ _ _ stackStockFul = stackStockFul checkState ( input : inputs ) s t a t e stateTable stackStock1 stackStock2 stackStockFul =

36

37

38

39

40

41

42

43

44

i f ( f o l g Z == [ ] ) then checkState inputs state stateTable stackStock2 stackStockFul stackStock1

45

46

47

else case t a g of " /TD" " /TH" " /TR" > closeTDTH > closeTDTH >

48

49

50

51

52

if ( state < 4 ) then closeTR else anythingElse _ where ( tag , v a l u e ) = intKA i n p u t > a n y t h i n g E l s e

53

54

55

56

57

35

58

folgZ stateTable

= f i n d F o l l o w S t a t e ( tag , s t a t e ) v a l u e

59

closeTDTH

= c h e c k S t a t e i n p u t s ( head f o l g Z ) s t a t e T a b l e [ ]

( ( reverse s t a c k S t o c k 1 ) : s t a c k S t o c k 2 ) s t a c k S t o c k F u l
60

closeTR

= c h e c k S t a t e i n p u t s ( head f o l g Z ) s t a t e T a b l e [ ]

[ ] ( ( reverse s t a c k S t o c k 2 ) : s t a c k S t o c k F u l )
61

a n y t h i n g E l s e = c h e c k S t a t e i n p u t s ( head f o l g Z ) s t a t e T a b l e ( s t a c k A c t i o n s t a c k S t o c k 1 ( tag , s t a t e ) v a l u e s t a t e T a b l e ) stackStock2 stackStockFul

62

s t a c k A c t i o n : : [ String ] > ( String , Integer ) > String > [ ( ( String , Integer ) , ( Integer , String ) ) ] > [ String ] stackAction stackStock _ _ [ ] = stackStock s t a c k A c t i o n s t a c k S t o c k i n p u t F o l l o w v a l u e ( ( s t a t e I n f o , (_ , action ) ) : rest ) =

63

64

65

66

67

i f ( i n p u t F o l l o w == s t a t e I n f o ) then doAktion s t a c k S t o c k v a l u e a c t i o n else stackAction stackStock inputFollow value r e s t doAktion : : [ String ] > String > String > [ String ]

68

69

70

71

72

73

doAktion s t a c k S t o c k f i n d e d D a t a s a c t i o n = case a c t i o n of | Save t h e f i n d e d d a t a s i n a l i s t "PUSH" > findedDatas : stackStock

74

75

76

77

| Return t h e s t a c k when no a c t i o n a v a i l a b l e _ > s t a c k S t o c k f i n d F o l l o w S t a t e : : ( String , Integer ) > String > [ ( ( String , Integer ) , ( Integer , String ) ) ] > [ Integer ]

78

79

80

findFollowState _ _ [ ] = [ ] f i n d F o l l o w S t a t e i n p u t v a l u e ( ( s t a t e I n f o , ( f o l l o w S t a t e V a r , _) ) : rest ) =

81

82

i f ( i n p u t == s t a t e I n f o ) then [ followStateVar ]

83

84

36

85

else findFollowState input value r e s t Listing A.1: Implementierung des Tabellen gesteuerten Zustandsautomaten

86

37

ZName 7 0 PUSH/2 PUSH/3 1 2 3

Zustand

TR1 /TR TH1 TEXT1TH /TH1 TD1

TEXT1TD /TABLE1

SearchTR

SearchTH1/TD1 1

SearchText1TH

SearchText1TD

ACCEPT
Tabelle A.1: Zustandstabelle linker Teil

38 /TABLE2 TR2 /TR2 TD2 /TD2 TEXT2 IMAGE 4 3 5 4 6 5

Tabelle A.2: Zustandstabelle rechter Teil

ZName

Zustand

/TD1 TABLE2

SearchText1TD

ReadSlots

SearchSlotTD

SearchSlotText

PUSH/6 PUSH/6

Glossar
Krzel JSON Beschreibung JavaScript Object Notation ist ein Datenformat

Parser

Ist ein Computerprogramm fr die Zerlegung und Umwandlung einer beliebigen Eingabe in ein brauchbares Format

Regulre Ausdrcke

Beschreibt eine Menge mit Hilfe bestimmter syntaktischer Regeln

Rekursion REST

Eine Funktion, die sich selber aufruft Representational State Transfer

Slot

Ein Slot ist ein Bereich, in dem mehrere Veranstaltungen zu einem bestimmten Tag und Zeitpunkt dargestellt werden

SSL

Secure Sockets Layer

TLS Transitional

Transport Layer Security vorbergehend

39

Abbildungsverzeichnis
1.1 1.2 Projektbersicht von Spirit. Quelle: Abbildung von Florian Schuhmann. Stundenplan BaI6 Ausschnitt. Quelle: http://sund.de/steffen/plan/ s_bai6.html. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 5.1 4 2

Transformationsschritte. Quelle: Eigene Darstellung. . . . . . . . . . . 19 Zustnde fr den Tabellen Kopf. Quelle: Eigene Darstellung. . . . . . 20 Zustnde fr den Tabellen Krper. Quelle: Eigene Darstellung. . . . . 20 Zusammensetzung der erweiterten internen Datenstruktur. Quelle: Eigene Darstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 5.3

Dozenten-Datenbestand. Quelle: Eigene Darstellung.

. . . . . . . . . 28

Kommunikation mit RESTful Service. Quelle: Eigene Darstellung. . . 30

40

Tabellenverzeichnis
3.1 Tabelle zur Verfahrensauswertung . . . . . . . . . . . . . . . . . . . . 14

A.1 Zustandstabelle linker Teil . . . . . . . . . . . . . . . . . . . . . . . . 38 A.2 Zustandstabelle rechter Teil . . . . . . . . . . . . . . . . . . . . . . . 38

41

Listings
3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 5.1 Tabellenaufbau des alten Stundenplans . . . . . . . . . . . . . . . . . Unterschied wchentlich oder alle zwei Wochen . . . . . . . . . . . . . 8 9

Unterschied bung/Vorlesung . . . . . . . . . . . . . . . . . . . . . . 10 Darstellungsform des HTML Codes . . . . . . . . . . . . . . . . . . . 11 TagSoup Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 TagSoup Datentyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Aufbau der Zwischenstruktur . . . . . . . . . . . . . . . . . . . . . . 18 Aufbau der internen Datenstruktur . . . . . . . . . . . . . . . . . . . 22 Ausschnitt aus der Zwischenstruktur . . . . . . . . . . . . . . . . . . 23 Grund fr eine Zwischenstruktur . . . . . . . . . . . . . . . . . . . . 24 Zwischenstruktur Vorlesung u . . . . . . . . . . . . . . . . . . . . . . 24 Stundenplan Beispiel mit Zusatzinformationen . . . . . . . . . . . . . 28

A.1 Implementierung des Tabellen gesteuerten Zustandsautomaten . . . . 34

42

Literatur
Braun, Prof. Dr. Oliver. PADS. 2011. url: http://pads.fh-schmalkalden. de/spirit.html (besucht am 21. 08. 2011). Bringert, Bjorn. xhtml. 2011. url: http://hackage.haskell.org/package/ xhtml (besucht am 21. 07. 2011). Herold, Helmut. UNIX und seine Werkzeuge lex und yacc. Mnchen, Paris: Addison-Wesley, 1992. Lengauer, Prof. Christian. Funktionale Programmierung(Uni-Passau). 2011. url: http://www.infosun.fim.uni- passau.de/cl/lehre/funcprog05/ wasistfp.html (besucht am 01. 09. 2011). Ldicke, Benjamin. Evaluierung und Konguration von einem NoSQL- und relationalen DBMS sowie die Konzeption und Entwicklung eines Datenbankservice auf Basis von RESTful Web Services in Scala. zur Zeit in Arbeit, Abgabe voraussichtlich September 2011. Magisterarb. Blechhammer 9, 98574 Schmalkalden: Fachhochschule Schmalkalden, 2011. Mitchell, Neil. tagsoup. 2011. url: http://hackage.haskell.org/package/ tagsoup (besucht am 21. 07. 2011). tagsoupTag. 2011. url: http://hackage.haskell.org/packages/archive/ tagsoup-ht/0.3/doc/html/Text-HTML-TagSoup-HT-Tag.html (besucht am 11. 08. 2011). Schmitt, Franz Josef. Praxis des Compilerbaus. Mnchen Wien: Carl Hanser Verlag Mnchen Wien, 1992.

43

Van der Jeugt, Jasper und Simon Meier. blaze-html. 2011. url: http:// hackage.haskell.org/package/blaze-html (besucht am 21. 07. 2011). Verfasser, ohne. Funktionale Programmierung(Wikipedia). 2011. url: http : / / de . wikipedia . org / wiki / Funktionale _ Programmierung (besucht am 31. 08. 2011). HTTPS. 2011. url: http://en.wikipedia.org/wiki/HTTPS (besucht am 09. 08. 2011). Lexikalische Analyse. 2011. url: http : / / de . wikipedia . org / wiki / Compiler#Lexikalische_Analyse (besucht am 18. 07. 2011). Parsec. 2011. url: http://www.haskell.org/haskellwiki/Parsec (besucht am 18. 07. 2011). Parser. 2011. url: http://de.wikipedia.org/wiki/Parser (besucht am 22. 08. 2011). REST. 2011. url: http://de.wikipedia.org/wiki/Representational_ State_Transfer (besucht am 13. 08. 2011). W3C. W3CValidator. 2011. url: http : / / validator . w3 . org (besucht am 21. 07. 2011). Wallace, Malcolm. HaXml. 2011. url: http://projects.haskell.org/HaXml/ (besucht am 21. 07. 2011).

44

Ehrenwrtliche Erklrung
Hiermit erklre ich an Eides Statt, dass ich die vorliegende Bachelorarbeit selbstndig und ohne Benutzung anderer, als der angegebenen Hilfsmittel, angefertigt habe. Die aus fremden Quellen direkt oder indirekt bernommenen Gedanken sind als solche kenntlich gemacht. Diese Bachelorarbeit hat in gleicher oder hnlicher Form keiner anderen Prfungsbehrde vorgelegen.

Schmalkalden, den 05.09.2011 Schmalkalden, den 05.09.2011 Christian Linde

45