Lade Inhalt...

Adressenidentifizierung in Textumgebungen

Evaluierung der Skriptsprache Groovy

von Fabian Deitelhoff (Autor) Christof Geisler (Autor)

Ausarbeitung 2011 62 Seiten

Informatik - Angewandte Informatik

Leseprobe

Inhaltsverzeichnis

Abkurzungs- und FremdwOrterverzeichnis

Abbildungsverzeichnis

Listingverzeichnis

1 Abstract

2 Einleitung

3 Aufgabenstellung
3.1 Ist-Zustand (Problembeschreibung)
3.2 Soll-Zustand
3.3 Definition einer Adresse
3.3.1 Definition des Aufbaus des Namens
3.3.2 Definition der Strafienangabe inklusive Hausnummer
3.3.3 Definition Postfachbezeichnung
3.3.4 Definition von Postleitzahl und Ort
3.4 Mustererkennung

4 Auswahl der Programmiersprache
4.1 Bedingungen an die Programmiersprache
4.2 Mogliche Skriptsprachen
4.3 Merkmale von Groovy

5 Entwicklungsumgebung
5.1 Integrierte Entwicklungsumgebung (IDE)
5.2 Automatisiertes Testen
5.3 Testuberdeckung
5.4 Versionsverwaltung
5.5 UML-Diagramme
5.6 Sonstige Zeichnungen
5.7 Eingesetzte Frameworks

6 LOsung
6.1 Offizielle Definition einer Adresse
6.2 Musteradressen zur Algorithmusuberpriifung
6.3 Projektstruktur der Anwendung
6.3.1 Aktuelle Probleme
6.4 Prozesskette
6.4.1 Entwurf 1
6.4.2 Entwurf 2
6.4.3 Entwurf 3
6.4.4 Entwurf 4
6.4.5 Entwurf 5
6.4.6 Entwurf 6
6.4.7 Entwurf 7
6.4.8 Entwurf 8
6.5 Objektorientiertes Design
6.5.1 Merkmale der geplanten Architektur
6.5.2 Einflusse auf die Architektur
6.5.3 Das Model-View-Controller Prinzip
6.5.4 Kommunikation der Komponenten
6.5.5 Registrierbare Datenquellen
6.5.6 Registrierbare Aktionen
6.5.7 Hauptkomponenten
6.5.8 Utility-Komponenten
6.5.9 Vollstandige Testabdeckung
6.6 Algorithmen zur Adresserkennung
6.6.1 Filereader
6.6.2 Tokenizer
6.6.3 Landercodefilter
6.6.4 Postleitzahlendetektor
6.6.5 Validierung der Postleitzahlen
6.6.6 Namenvalidierung Grosskundenadressen
6.6.7 Strafienvalidierung Standardadressen
6.6.8 Namenvalidierung Standardadressen

7 Ausblick
7.1 Architektur
7.2 Algorithmen

8 Erklarung

Literaturverzeichnis

A Ablauf vollstandiger Algorithmus

B Entwurfe

C Bericht zur Testabdeckung

D Die Klasse NormalStreetValidator.groovy

E Die Methode validateNormalName.groovy

Abbildungsverzeichnis

1 Screenshot der Projektstruktur in IntelliJ

2 Grundsatzliche Struktur des Prozessablaufs

3 Achter und finaler Entwurf der Prozesskette

4 Allgemeiner Aufbau einer auf EBC basierenden Kommunikation

5 Ablauf beim Feuern eines Events

6 Ablaufdiagramm Postleitzahlendetektor

7 Ablaufdiagramm Postleitzahlenvalidator

8 Ablaufdiagramm Namenvalidierung

9 Ablauf des vollstandigen Algorithmus als Aktivitatsdiagramm

10 Erster Entwurf der Prozesskette

11 Zweiter Entwurf der Prozesskette

12 Dritter Entwurf der Prozesskette

13 Vierter Entwurf der Prozesskette

14 Funfter Entwurf der Prozesskette

15 Sechster Entwurf der Prozesskette

16 Siebter Entwurf der Prozesskette

17 Bericht zur Testabdeckung des gesamten Projekts

1 Zugriff auf Klassenvariablen

2 Automatische ActionListener in Groovy

3 Event-Kommunikation mit Groovy-Closures

4 Mehrere Beobachter an einem Event

5 Ermitteln von Daten registrierter Datenquellen

6 Ermitteln von registrierten Aktionen

7 Regularer Ausdruck Postleitzahlenvalidierung unkommentiert

8 Regularer Ausdruck Postleitzahlenvalidierung kommentiert

9 Regularer Ausdruck zur Strafienvalidierung

10 Regularer Ausdruck zur Titelerkennung

11 Variablentausch mit Groovy

12 Klasse NormalStreetValidator

13 Methode validateNormalName

1. Abstract

This elaboration handles the identification and classification of address information. Fur­thermore it was an experiment for scripting languages in the Java environment and the test, if they can handle such tasks. The prototype - written in Groovy - can detect dif­ferent address information and can handle the classification of corporate address data and accordingly other address data, classified as normal address data. The main goal and achievement is the development of a generic and for future development extendable soft­ware architecture. It is possible to extend the infrastructure to detect more address types, extract more address information and attach external data sources, like web services or commercial address databases. The prototype is made up of an new event communication mechanism and exert regular expressions for pattern matching.

2. Einleitung

Die vorliegende Ausarbeitung wurde als Klausurleistung fur das Modul Skriptsprachen im Studiengang Angewandte Informatik der Fachhochschule Sudwestfalen erstellt. Sie ent- stand in Zusammenarbeit mit der NeoScio Unternehmergesellschaft in Iserlohn im Rah- men eines zweiwochigen Projekts vor Ort am Unternehmenssitz.

Wir mochten uns an dieser Stelle herzlich fur die gute Betreuung und das Engagement von Herrn Prof. Dr.-Ing. Fritz Mehner bedanken. Durch sein Engagement haben wir die Moglichkeit bekommen, die Ausarbeitung mit einem sehr interessanten Themengebiet bei der NeoScio Unternehmergesellschaft zu bearbeiten.

Unser Dank gilt auch Herrn Sven Ruppert, unser Ansprechpartner und Betreuer bei der Firma NeoScio, der uns mit Rat und Tat in allen Belangen der Ausarbeitung und des Projektmanagements zur Seite stand.

3. Aufgabenstellung

3.1. Ist-Zustand (Problembeschreibung)

Fernziel der gestellten Aufgabe ist das Auslesen von Adressen aus deutschen Internetsei- ten. In Deutschland regelt das Telemediengesetz (TMG) [1] die Impressumspflicht fur Betreiber von Internetseiten. Aus diesem Grunde ist davon auszugehen, dass auf nahe- zu jeder Internetseite mit Endung ’.de’ eine gultige Adresse der verantwortlichen Person vorhanden ist. Einzige Ausnahme bilden hier rein private Internetseiten, welche unter bestimmten Voraussetzungen von der Impressumspflicht ausgenommen sind.

Fur die Auswahl der zu untersuchenden Internetseiten werden Filter eingesetzt, um bran- chenspezifisch nach Adressen suchen zu kOnnen. Die so vorsortierten Seiten werden ent- sprechend nach Impressum oder Kontakt untersucht. Die auf diesen Unterseiten enthal- tene Adresse wird extrahiert und zur Weiterverarbeitung aufbereitet.

Diese Erkennung ist fur sich bereits eine sehr komplexe Teilaufgabe. Adressen konnen in sehr verschieden Arten und weisen dargestellt werden. Nicht immer geschieht diese Darstellung nach der geltenden Norm. So sind hier sehr viele moogliche Schreibweisen abzufangen.

Werden Adressen automatisiert erkannt und ohne menschliche Kontrolle weiterverwen- det, so sind an die sichere Erkennung sehr hohe Anforderungen zu stellen. Eine falsch geschriebene Adresse kann beim Empfanger Emporung und Ablehnung auslosen. Dies ist insbesondere beim Verwenden der Adressen fur Marketingzwecke kontraproduktiv und muss unbedingt vermieden werden.

Im Anfangsstadium ist eine Moglichkeit einzubauen, welche anzeigt, dass die Adresse nochmals „von Hand“ zu tiberprtifen ist. Diese Funktion kann auch bei fortgeschrittenen Versionen verwendet werden, um nicht eindeutige Adressen anzuzeigen.

Die Plausibilitatsprufung der erkannten Adresse kann mit Hilfe verschiedener externer Datenquellen geschehen. So lassen sich eine gefundene funfstellige Postleitzahl und der dazugehorige Ortsname mit einer Postleitzahlendatenbank abgleichen. Fur diese Daten- bank gibt es mehrere mogliche Quellen. Je nach Bedarf und gewunschter Aktualitat kann sowohl auf freie als auch auf kommerzielle Angebote zurackgegriffen werde. MOgliche kommerzielle Quellen sind z.B. die Deutsche Post [2] oder Privatunternehmen wie ’Geo­Postcodes’ [3]. Die Angebote dieser Unternehmen sind kostenpflichtig, stellen aber nach Information in der Selbstdarstellung aktuelle Daten zur Verfugung. Bei einem produktiven Einsatz der Software ist ein aktueller Datensatz unbedingt notig.

Zu Testzwecken und bei der Entwicklung kann auch auf frei zugangliche Datenbestande zurtickgegriffen werden. Eine Moglichkeit stellt die offene Quelle ’OpenGeoDB’ [4] dar. Die von ’OpenGeoDB’ zur Verfugung gestellten Daten beinhalten zur Zeit aber nur Post- leitzahlen und Orte, Strafiennahmen sind vorgesehen, aber noch nicht implementiert. Die Aktualitat der Daten ist unbedingt zu prufen.

Zur Uberprufung der Plausibilitat des gefundenen Strafiennamens ist eine Datenbank notig, welche uberpruft ob dieser Strafienname zum Ort und zur Postleitzahl passt. Zu Testzwecken ist es moglich, einen Datenbestand von der Internetseite der Universitat Pa- derborn herunter zu laden [5]. Dieser ist allerdings aus der Zeit kurz nach der Umstellung auf funfstellige Postleitzahlen und entsprechend veraltet. Zu Testzwecken aber durchaus brauchbar.

Eine weitere Moglichkeit fur die Strafienvalidierung ist der Abgleich mit einem Daten­bestand, welcher alle zu einer Strafie existierenden Hausnummern entholt. Ein Beispiel fur den Einsatz eines solchen Datenbestandes findet sich z.B. auf der Internetprdsenz des Bodenrichtwertinformationssystems NRW [6]

Die als gultig erkannte Adresse wird abschliefiend in eine Datenbank gespeichert. Die Datenbank ist so zu erstellen, dass die Komponenten der Adresse und weitergehende Informationen einzeln abrufbar sind.

Insgesamt gibt es zu dieser Aufgabenstellung bis heute keine zufriedenstellende Losung. Die Eindeutigkeit der Erkennung im Text bereitet bereits grofie Probleme und eine defi­nitive Bestimmung gestaltet sich als dufierst schwierig.

3.2. Soll-Zustand

Um in einem Rahmen von zwei Wochen zu einem brauchbaren Ergebnis zu gelangen, haben wir uns in Abstimmung mit der betreuenden Firma und dem betreuenden Dozenten auf die Bearbeitung eines Ausschnittes aus oben genannter Aufgabenstellung geeinigt. Es sollen in einer Datei ubergebene, bereits bearbeitete Datensotze weiterverarbeitet werden. Die zu bearbeitenden Datensotze enthalten eine Adresse, welche bereits grob in Zeilen aufgeteilt ist.

Die Zuordnung zu den einzelnen Kategorien wie Name, Strafie, Titel etc. soll die zu er- stellende Software tibernehmen. Als Ergebnis soll ein Adress-Objekt ubergeben werden, dessen Attribute die entsprechenden Daten enthalten und welches von nachgeschalteter Software weiterverarbeitet verarbeitet werden kann. Denkbare Moglichkeit ist das Spei- chern in einer Datenbank.

Da der zu implementierende Programmteil keinerlei Visualisierungen benotigt, wird auf grafische Progammkomponenten komplett verzichtet.

Es soll unterschieden werden zwischen Grofikundenadressen und normalen Adressen. Un- ter normale Adressen fallen Adressen mit nicht mehr als 5 Zeilen. Postfachadressen und Adressen mit Strafienname sollen im Ergebnis erkannt und unterschieden werden konnen.

Redundante Komponenten der Adresse werden entfernt. Dies sind explizit eine Landerken- nung vor der Postleitzahl oder eine Landerkennung in einer Zeile unterhalb der eigentlichen Adresse. Kennungen vor der Postleitzahl werden ungeprlift gestrichen, Landerkennungen unterhalb der Adresse werden mit einer Liste moglicher Kennungen verglichen und ent­fernt.

In dem Ergebnis-Objekt sind alle zur richtigen Adressierung [7] notigen Informationen enthalten. Eine beim Adressieren optionale Angabe des Ortsteils in der Zeile vor der Strafienangabe wird in der Umsetzung nicht beriicksichtigt. Es konnten keine entspre- chenden Datenquellen ermittelt werden und diese Schreibweise ist sehr ungewohnlich. Bei einem kommerziellen Einsatz der Software ist dies zu beachten.

3.3. Definition einer Adresse

Um den Aufwand fur die Adressenerkennung abzugrenzen sind an die zu ubergebenden Dateien folgende Anspruche zu stellen:

- Es werden nur Adressen aus Deutschland betrachtet.
- Leerzeilen werden aus den Adressen gefiltert (per Definition).
- Eine Adresse pro Datei.
- Eine Adresse mit 3-5 Zeilen ist eine Privat- oder Firmenadresse.
- Eine Adresse mit nur zwei Zeilen ist eine Grofikundenadresse.
- Grofi- und Kleinschreibung wird nicht beachtet.

3.3.1. Definition des Aufbaus des Namens

Unterschieden wird bei den Namen fur Grofikundenadressen und Namen fur normale Adressen. Namen von Grofikundenadressen sind eindeutig definiert und konnen mit einer Datenbank abgeglichen werden. Fur spotere Programmversionen ist vorzusehen, dass auch nicht vollig korrekt geschriebene Adressnahmen zur Erkennung der Adresse ftihren.

Bei der Bearbeitung von normalen Adressen sind folgende Angaben zu uberprtifen, um festzustellen, ob ein gtiltiger Name vorliegt:

- Vornamen ohne Bindestriche
- Maximal zwei Worter durch Bindestrich verbunden (Nachname)
- Erst mal keine Beschrankung auf die Anzahl der Worter
- Keine Ziffern in den Wortern
- Grofi- und Kleinschreibung wird nicht beachtet
- Anreden sind per Definition „Herr“, „Frau“, „Familie“, „Fam.“. Diese Liste wird aus einer erweiterbaren Datei gelesen.
- Titel sind ,,Prof.“, ,,Professor“, ,,Dr.“, ,,Doktor“, ,,med.“, ,,rer.“, „Dipl.“, ,,Ing.“.

Ftir folgende Programmversionen sollte die Moglichkeit bedacht werden, dass eine Adresse mehrere Namen, getrennt durch ein Verbindungswort enthalten kann. Mogliche Verbin- dungsworter waren ,,und“, „u.“, ,,,“. Hierbei ist dann auch noch zu unterscheiden, ob das Verbindungswort zwei komplette Namen verbindet oder nur zwei Vornamen bezuglich einem Nachnamen. Auch ein Zeilenumbruch kann als Trennung von zwei Namen imple- mentiert werden. Dabei werden gegebenenfalls noch weitere Uberprufungen notig.

3.3.2. Definition der StraBenangabe inklusive Hausnummer

Der Strafienname sollte wie bereits in Kapitel 3.1 erwahnt mit Hilfe einer Datenquelle auf Plausibilitat uberpruft werden. Hilfsweise konnte gepruft werden, ob in dem potentiellen Strafiennamen ein Schlusselwort wie ,,Strafie“, ,,Str.“, ,,Weg“, ,,Platz“, ,,Allee“ enthalten ist. In Anbetracht der zu erwartenden Fehlerquote wird auf diesen Hilfstest aber verzichtet. Der gefundene Name wird als Strafienname angenommen.

Bleibende Kriterien sind:

- Kombination aus Wortern und einer Zahl. Die Zahl steht am Ende der Zeile und kann durch einen direkt oder mit Leerzeichen angefuogten Buchstaben ergoanzt sein.
- Grofi- und Kleinschreibung wird nicht beachtet
Hier ist noch Potential fur eine Einzelprufung gegeben: Hausnummern in Deutschland haben maximal vier Ziffern. Und wenn eine Hausnummer vier Ziffern hat, dann ist die Strafie in Koln. [8]

3.3.3. Definition Postfachbezeichnung

Folgende Kriterien gelten zur Identifikation einer Postfachadresse:

- Mogliche Postfachbezeichnungen sind ,,Postfach“, ,,Pf“, ,,Pf.“ oder ,,Postf.“. Diese Anfangsbezeichnungen sollen spoter in einer erweiterbaren Liste gespeichert werden, damit eine Anpassung ohne Anderung am Quelltext erfolgen kann.
- Die Postfachnummer besteht aus 2 bis 6 Ziffern, welche durch Leerzeichen getrennt sein koonnen.
- Grofi- und Kleinschreibung wird nicht beachtet

3.3.4. Definition von Postleitzahl und Ort

Auch die Untersuchung auf der Kombination Postleitzahl / Ort wird auf das ubernehmen der gefundenen Angaben reduziert. Es ist fur spdtere Erweiterungen der Software be- sonders wichtig, diese Uberprafung mit Hilfe einer externen Datenbank durchzufuhren.

Die Postleitzahl mit funf Ziffern ist das wichtigste Erkennungsmerkmal einer Adresse und sollte unbedingt zum Ort passen.

Zu untersuchende Kriterien sind:

- Funf zusammenhangende Ziffern am Anfang. Eventuell mit einer fuhrenden Lander- kennung.
- Gefolgt von bis zu vier WOrtern.
- Grofi- und Kleinschreibung wird nicht beachtet.

3.4. Mustererkennung

Als Mustererkennung wird allgemein die Fahigkeit bezeichnet, in einer Menge von Daten Regelmafiigkeiten, Wiederholungen, Ahnlichkeiten oder Gesetzmafiigkeiten zu erkennen um daraus weitere Schlusse zu ziehen (siehe [9]).

Das Erkennen und Klassifizieren von Mustern kommt in vielen Bereichen zum Einsatz. Beispielsweise bei der Auswertung von Bilddaten mithilfe der automatischen Bildverar- beitung, bei der Erkennung von Sprache oder der Auswertung von Texten. Uberall mussen Muster erkannt und korrekt aus den umgebenen Daten herausgelost werden. In dieser Aus- arbeitung liegt der Schwerpunkt aber, wie weiter vorne schon beschrieben, nicht bei dem Herauslosen der Adresse aus umgebenen Text, sondern es sollen die einzelnen Bestandteile der Adresse erkannt werden. Da die Adressen als Textdateien vorliegen, scheiden alle nicht textuellen Verfahren aus. Weitere Moglichkeiten bestehen zum Beispiel in der Benutzung von neuronalen Netzen [10] und Support Vector Machines [11], um nur zwei Beispiele zu nennen. Diese Themen erfordern aber eine graofiere Einarbeitung und scheiden wegen der kurzen Projektlaufzeit somit aus.

In der Ausarbeitung eingesetzt werden letztendlich regulare Ausdriicke, die schon in Java gut unterstutzt werden. Diese Unterstutzung wurde in Groovy nochmals ausgebaut, um zum Beispiel im Quelltext direkt damit arbeiten zu konnen. Beispielsweise in Abfragen oder Zuweisungen, was einer Skriptsprache wiederum naher kommt. Wo regulare Aus- drucke konkret zum Einsatz kommen und welchen Zweck sie erfullen, ist im Kapitel 6.6 naher beschrieben.

4. Auswahl der Programmiersprache

4.1. Bedingungen an die Programmiersprache

Die Erstellung der Ausarbeitung erfolgt bei der Firma NeoScio Unternehmergesellschaft in Iserlohn. Die entwickelte Software soll in der Arbeitsumgebung der Firma ganz oder teilweise zum produktiven Einsatz kommen. Da die Firma NeoScio Unternehmergesell- schaft aberwiegend mit der Programmiersprache Java arbeitet, ist es sehr wichtig, dass die im Rahmen der Ausarbeitung Skriptsprachen zu erstellende Software ebenso von der Java Virtual Machine (JVM) ausgefuhrt werden kann.

Zusatzlich soil die Programmiersprache Elemente einer modernen Skriptsprache haben, da der Bezug zu der Lehrveranstaltung Skriptsprachen herzustellen ist. Da die Einarbei- tung in die neue Skriptsprache zum grofien Teil wahrend der Ausarbeitung stattfinden wird, ist ein moglichst einfacher Syntax von Vorteil. Da es sich um eine hohere Program­miersprache mit entsprechender Komplexitat handeln wird, ist dieser Punkt nur bedingt zu erfullen.

Auch die Integration in eine moderne integrierte Entwicklungsumgebung (IDE) soll beach- tet werden. Bei der Firma NeoScio wird hauptsachlich IntelliJ von JetBrains eingesetzt. Eine Integration der ausgewahlten Skriptsprache in diese Umgebung ware von Vorteil, ist aber nicht zwingend notwendig. Da die Entwicklung des Prototypen zukunftssicher sein und schon recht fruh eine moglichst stabile Version vorliegen soll, werden wahrend der Entwicklung verstarkt Unit-Tests und die Testuberdeckung als Metrik eingesetzt. Auch diese Punkte sind in Bezug zur moglichen Untersttitzung bei der Wahl der Programmier­sprache und der IDE zu berucksichtigen.

4.2. Mogliche Skriptsprachen

Die Recherche zu dieser Ausarbeitung hat eine grofie Menge an Skriptsprachen zu Tage gefordert, welche auf der JVM ausgefuhrt werden konnen. Ausfuhren bedeutet an dieser Stelle, dass sie in der Regel kompiliert und in Java Bytecode uberfuhrt werden. Diese ungefilterte Menge wurde auf die gangigsten Skriptsprachen eingeschrankt:

- Groovy
- JRuby
- Scala
- Fantom
- Jython (ehemals JPython)

Das sind die zur Zeit am weitesten verbreiteten Skriptsprachen, die auf der JVM aus- geftihrt werden kdnnen. Die Definition von Skriptsprache ist hierbei so zu verstehen, dass alle diese Sprachen mit vereinfachtem Syntax fur schnelles und tibersichtliches Program- mieren daherkommen. An diesem Punkt kdnnte man nattirlich noch konkretere Ansprtiche festmachen, die Moglichkeiten der aufgezahlten funf genugen aber den oben aufgefuhrten Bedingungen.

JRuby und Jython sind, wie der Name bereits vermuten lasst, von den klassischen Skript­sprachen Ruby bzw. Python abgeleitet. Diese Programmiersprachen bieten den Vorteil, dass sie wegen ihrer etablierten Vorbilder sehr gut dokumentiert sind. Sowohl JRuby als auch Jython sind objektorientiert und vollstandig in die Java-Umgebung integriert. Die ganzen Mdglichkeiten, die in Java zur Verfugung stehen, stehen auch diesen Skriptspra­chen zur Verfiigung. Das macht sie ihren Originalen gegenuber noch attraktiver. Wir haben uns fur diese Ausarbeitung auch nicht gegen diese Sprachen entschieden, sondern fiir eine andere.

Scala ist eine Programmiersprache, welche sowohl von der JVM als auch unter der .NET- Umgebung ausgeftihrt werden kann. Die Mdglichkeit der Integration in .NET-Projekte wird aktiv von der Firma Microsoft vorangetrieben [12]. Auch Scala enthalt viele Elemen- te einer Skriptsprache. Im grofien und ganzen erscheint sie aber etwas sperriger als andere zur Verfugung stehende Moglichkeiten. Der Einarbeitungsaufwand scheint gegenuber den anderen Sprachen deutlich erhaht, was den Moglichkeiten dieser Sprache naturlich nicht entgegensteht. Vielmehr gilt Scala neben Java als die schnellste Sprache und Parallel- ausfuhrung von Prozessen gehort zum Konzept.

Fantom gehort wie Scala zu den Programmiersprachen, die sowohl von der JVM als auch von der CLR des .NET-Frameworks ausgefuhrt werden konnen. Zusatzlich wird noch mit der Unterstutzung von JavaScript geworben. An modernen Konzepten mangelt es auch Fantom nicht. So ist funktionales Programmieren, Closures und eine Mischung aus stati- scher und dynamischer Typisierung moglich. Aufgrund der Portabilitat hin zu JavaScript ist auch eine JSON-ahnliche Serialisierung enthalten. Die Grande gegen Fantom sind rein asthetischer Natur. Die Syntax bei Closures und die Organisation in PODs anstatt in Namensraumen waren mit dafur entscheidend, eine andere Skriptsprache zu wahlen.

Die Entscheidung ist letztendlich fur Groovy gefallen. Diese Sprache zeichnet sich auch durch eine Vielzahl von syntaktischen Verbesserungen und Erleichterungen aus. Das fuhrt dazu, dass ein zu Java-Code aquivalenter Groovy-Quelltext teilweise mit einer viel geringe- ren Anzahl von Zeilen realisiert werden kann. An Features der Sprache selbst steht Groovy keiner der oben bereits beschriebenen Sprache nach. Entscheidend fur die Auswahl von Groovy waren die gute Integration in die IntelliJ Entwicklungsumgebung (siehe 5.1) und die breite Untersttitzung von Test-Frameworks, um Unit-Tests (siehe 5.2) entwickeln zu koannen.

4.3. Merkmale von Groovy

Eine Auswahl von Besonderheiten und Merkmalen, die in der dieser Ausarbeitung benutzt werden, sind in diesem Kapitel beschrieben. Das beugt Missverstandnissen beim Lesen der Beispielquelltexte und des Prototypen vor.

Die herausragendsten Merkmale, auf die man bei der Arbeit mit Groovy sehr schnell stafit, sind die Vereinfachungen der Syntax und das dynamische Typsystem. Wenn man Java kennt, wird schnell klar, dass die Syntax sehr weit in Richtung Skriptsprache gerutscht ist. So koannen Semikolons am Ende weggelassen werden und die Arbeit mit Listen wurde stark vereinfacht, um nur zwei kleine Beispiele zu nennen. So reicht es aus, eine Variable mit [] zu initialisieren, um eine ArrayList zu erhalten. Ein Doppelpunkt zwischen den eckigen Klammern macht aus der ArrayList eine HashMap, so dass mittels Schlusseln auf die Elemente zugegriffen werden kann. Und das alles, ohne einen Typ angeben zu mussen. Soll eine Liste deklariert und initialisiert werden, reicht die folgende Zeile vollkommen aus:

Abbildung in dieser Leseprobe nicht enthalten

Auch das weitere Handling mit diesen Liste wurde vereinfacht. Durch die standardmafiige Uberladung des Plus-Operators steht ein einfaches Konstrukt zur Verfugung, um Listen aneinander zu haangen:

Abbildung in dieser Leseprobe nicht enthalten

Durch die dynamische Typisierung ist es dabei egal, welche Elemente zur Liste hinzu- gefligt werden. Auch der Listentyp wird dynamisch zur Laufzeit ermittelt. In einer Java- Umgebung wird das moglich, in dem alle Typen von Object erben. Die Angabe von def bewirkt also, dass der Typ Object verwendet wird. Zur Laufzeit wird dann entschieden, ob eine Typumwandlung moglich ist oder ob eine aufgerufene Methode irgendwo in der Vererbungshierarchie vorhanden ist.

Die oben genannten und noch weitere Merkmale wurden hauptsochlich bei der Imple- mentierung der Methoden benutzt. Die Merkmale von Groovy bzw. Java, die in die Ar- chitektur geflossen sind, werden im Kapitel 6.5.1 beschrieben.

5. Entwicklungsumgebung

Das folgende Kapitel beschreibt alle Entscheidungen und Richtlinien, welche die Entwick­lungsumgebung betreffen. Damit ist nicht ausschliefilich die integrierte Entwicklungsum­gebung (IDE) gemeint, sondern auch alle weiteren Werkzeuge und Erweiterungen, die wahrend der Projektlaufzeit zum Einsatz kamen.

5.1. Integrierte Entwicklungsumgebung (IDE)

Als integrierte Entwicklungsumgebung standen Eclipse der Eclipse Foundation [13] und IntelliJ von JetBrains [14] zur Verfugung. Beide bieten eine ohnlich komfortable Moglichkeit an, Java- bzw. Groovy-Anwendungen zu entwickeln. Fur den Einsatz von Groovy unter Eclipse muss ein zusotzliches Plugin [15] installiert werden, um beispielsweise den Com­piler einzubinden. Diese Unterstuotzung ist in IntelliJ schon von vornherein eingebaut und muss nicht extra nachinstalliert werden.

Die Wahl ist letztlich aus verschiedenen Griinden auf IntelliJ gefallen. Zum Einen sollte ei­ne neue IDE kennengelernt werden. Ein weiterer Grund ist, dass die Unterstutzung seitens NeoScio bzw. von Herrn Ruppert fur IntelliJ besser ist, da die Anwendung auch Firmen intern eingesetzt wird. Wohrend der Entwicklungsphase sind weitere Vorzuge von IntelliJ zum Vorschein gekommen. So wird wohrend der Arbeit der aktuelle entwickelte Quelltext von der IDE verarbeitet, was wesentlich bessere Meldungen zu Syntaxfehlern, ein umfang- reicheres und genaueres Refactoring und einen deutlich geringeren Speicherverbrauch im Vergleich zu Eclipse zur Folge hat.

5.2. Automatisiertes Testen

Wahrend der gesamten Projektlaufzeit sollen automatisierte Unit-Tests die Entwicklung der Anwendung begleiten. Diese automatisierten Tests konnen grob in zwei Kategorien unterteilt werden. Auf der einen Seite wird jede programmierte Klasse abgedeckt und die Funktionalitat dieser getestet. Diese Tests sind in der Projektstruktur unterhalb des Verzeichnisses impl-tests gruppiert. Zudem sollen Tests erstellt werden, die vollstandige Datensatze mit Adressbeispielen enthalten und so die gesamte Anwendung uberprufen konnen. Dadurch wird es moglich, den kompletten Algorithmus gegen viele verschiedene Adressen zu testen. Gruppiert werden diese Art von Tests unterhalb des Verzeichnis­ses addr-tests. Beide Verzeichnisse befinden sich unterhalb des Ordners tests in der Projektstruktur (vergl. 6.3). Zu beiden Kategorien gehoren auch Negativtests, die einen bestimmten Fehlerfall abpruafen.

Erstellt werden diese Tests mit dem JUnit-Framework in Version 4.8.1, das in der Stan- dardinstallation von IntelliJ bereits enthalten ist. Als Testdaten dienen Textdateien mit mehr oder weniger vollstandigen Adressdatensatzen bzw. mit speziell erstellten Daten, um Funktionstests fur alle Klassen erstellen zu konnen. Organisiert werden diese Testdaten auch in zwei verschiedenen Verzeichnissen, um der Verzeichnisstruktur der eigentlichen Test-Klassen zu entsprechen. Die Namen sind identisch zu den zwei bereits genannten, befinden sich aber unterhalb des Ordners test-data (vergl. 6.3).

5.3. Testiiberdeckung

Auch wenn automatisierte Unit-Tests ein zuverlassiges Mittel sind, um Klassen konse- quent auf Funktion zu uberprufen, kann die Aussage eines grunen Testlaufs tauschen. Ohne zu wissen, welche Quelltextzeilen der getesteten Klasse wirklich durchlaufen wur- den, ist eine konkrete Aussage uber die Funktionsfahigkeit der Anwendung nicht moglich. Auch ein erfolgreicher Testlauf kann je nach Testdaten Entscheidungen im Prozessablauf gar nicht oder nur mangelhaft ausfuhren.

Um diese Probleme zu beseitigen, wird die Testuberdeckung (Code-Coverage) von IntelliJ eingesetzt. Einmal in den Projekteinstellungen aktiviert, werden bei jedem Testdurchlauf die ausgefuhrten Zeilen uberpruft. Dadurch kann IntelliJ neben den Packages und Klassen die Qualitat der Uberdeckung angeben. Das geschieht mit Hilfe zweier Prozentangaben. Einmal der prozentuale Anteile der uberdeckten Klassen und zusatzlich der prozentuale Anteil der ausgefuhrten Zeilen.

Technisch basiert diese Technik auf dem bekannten Code-Coverage Tool EMMA [16], dass in der Java Welt zum Einsatz kommt. Die Uberdeckung wird auf Basis der ausgefuhrten Programmzeilen berechnet. Das erlaubt eine sehr genaue Analyse des vorliegenden Quell- textes. Zum Beispiel kann angezeigt werden, ob eine einzelne Zeile nur partiell uberdeckt wird. Dabei beeinflusst die aktivierte Testabdeckung die Ausfuhrungsgeschwindigkeit der Unit-Tests nicht wesentlich. In der Praxis konnte nur eine kleine Verzogerung festgestellt werden. Auch bei umfangreicheren Tests.

Detaillierte Informationen befindet sich im Kapitel 6.5.9 auf Seite 33.

5.4. Versionsverwaltung

Grundlage fur die reibungslose Zusammenarbeit der Projektteilnehmer und den Austausch von Projektdateien ist ein System zur Versionsverwaltung. Eingesetzt wird die freie Soft­ware Subversion, die unter der Apache-Lizenz 2.0 [17] steht. Zur Verfugung gestellt wird das Repository mit Namen adresserkennung von der Firma NeoScio. Dadurch dient es auch gleichzeitig als Austauschplattform mit Herrn Ruppert und als Datensicherung.

Ins Repository eingecheckt werden alle Dateien, die wahrend der Projektarbeit entstanden sind. Dazu zahlt vor allem der Quelltext der Anwendung, der als vollstandiges IntelliJ- Projekt eingecheckt wurde, und die Dokumentation, die als LTgX-Dokument erstellt wird. Bis auf eine aktuelle Version der Dokumentation sind grundsatzlich alle Dateien ausge- nommen, die durch irgendeinen Prozess generiert werden konnen.

5.5. UML-Diagramme

Zur besseren Visualisierung der Ablaaufe der einzelnen Algorithmen sollen Aktivitaats- diagramme zum Einsatz kommen. Sie erlauben es, auch umfangreichere Prozessablaufe ubersichtlich darzustellen. Fur die UML-Diagramme wird das Programm Visual Para­digm for UML [18] in der 30 Tage gultigen Enterprise Edition (Version 8.2) eingesetzt. In diesem Programm sind alle moglichen UML-Diagrammtypen vereint, so dass nicht eine Vielzahl von Anwendungen zum Einsatz kommen muss. Weitere Vorteile sind der Support von Herrn Ruppert, der das Programm selber einsetzt, und die Tatsache, dass es auch im funften Semester im Modul Software-Engineering zum Einsatz kommt. So kann schon eine vorherige Einarbeitung stattfinden.

5.6. Sonstige Zeichnungen

Fur weitere Abbildungen und Zeichnungen, wie zum Beispiel die Entwurfe im Kapitel 6.4, wird das Programm Microsoft Visio in der Version 2010 eingesetzt. Das Programm steht uns uber das MSDN Software Center zur Verfugung, fur dass die Fachhochschule Sudwestfalen die sogenannte acedemic allianz Lizenz besitzt. So kann es von Studenten kostenlos aus dem Portal heruntergeladen werden.

Mit dem Programm wurden in der Vergangenheit bei anderen Ausarbeitungen schon gute Erfahrungen gesammelt.

5.7. Eingesetzte Frameworks

Als Basis fur die Entwicklung des Prototypen dienen das Java SDK in Version 1.6.0 Update 26 und das Groovy Framework in Version 1.8.1. Die aktuelle stabile Version von Debian GNU/Linux enthalt in ihrer Paketverwaltung noch eine ultere Version 1.7.x. Aktuelle Versionen kbnnen von der Groovy-Homepage [19] heruntergeladen werden.

6. Losung

6.1. Offizielle Definition einer Adresse

Adressen im Sinne dieser Ausarbeitung sind Postanschriften mit konkreter physischer Empfangeranschrift oder Postfachadressen. Adressen von Grosskunden der Deutschen Post werden ebenfalls erkannt. Die Form von Adressen wird in Deutschland durch die DIN-Norm 5008 [20] geregelt.

Da wir nur Adressen aus Deutschland verarbeiten, haben wir uns uns entschieden, dass wir uns bezuglich der Definition von Adressen an den Hinweisen der Deutschen Post orientieren. Die auf der Internetseite der Deutsche Post beschriebene ’Gestaltung der Anschrift bei Inlandssendungen’ [21] ist eine Essenz der DIN 5008 bezuglich deutscher Inlandsadressen.

Wir untersuchen die gegebenen Daten auf Adresselemente, die zu einer korrekten Darstel- lung einer Adresse nach oben genannter Gestaltung notwendig sind. So ist sichergestellt, dass mit den ausgewerteten Informationen eine normgerechte Adressierung moglich ist. Sollten nicht alle Informationen enthalten sein oder nicht bestimmt werden konnen, so werden entsprechende Hinweise hinzugefugt.

Notige Angaben einer Standardadresse sind

- Name des Empfangers. Das Telemediengesetz bestimmt, dass ein Vor- und ein Nach- name des Verantwortlichen angegeben werden muss. Um die Software flexibler zu halten werden aber auch Namen zugelassen, welche nur aus einem Wort bestehen. Dieser Name wird dem Attribut Nachname zugewiesen.
- Strafie und Hausnummer oder Postfach und Postfachnummer. Bei der Schreibweise des Postfaches war es bis zur Einfuhrung der funfstelligen Postleitzahlen ublich die Postfachnummer bei grofieren Adressaten wegzulassen. Da dies heute durchaus noch gebrauchlich ist, kann uberlegt werden, ob die Software entsprechend angepasst wird, um auch Postfachadressen ohne Postfachnummer zuzulassen.
- Postleitzahl und Ort

Grofikundenaddressen besitzen eine eigene Postleitzahl und benotigen deswegen aufier dem Namen, Postleitzahl und Ort keine weiteren Angaben. Optionale Angaben wie Ab- teilung, Mitarbeitername etc. werden vorerst nicht beriicksichtigt.

6.2. Musteradressen zur Algorithmusuberprufung

Vom Programm werden normale Adressen und Grofikundenadressen erkannt. Ein Beispiel fur eine gultige Grofikundenadresse ist:

Mercedes-Benz AG 70322 Stuttgart

Eine normale, der Norm entsprechende Adresse ist diese:

Max Mustermann Musterstrasse 35 53789 Musterstadt

Diese Adresse enthalt nur notige Informationen fur die Eindeutigkeit. Zusatze wie eine vorangestellte Landeskennung sind fur die Eindeutigkeit nicht notig und sollen im na- tionalen Postverkehr auch weggelassen werden. Wird in der Adresse ein solcher Zusatz gefunden, so wird dieser nicht in den Datenbestand ubernommen. Die Anmerkungsliste enthalt aber einen entsprechenden Hinweis. Hier ein Beispiel:

Max Mustermann Musterstrasse 35 BRD-53789 Musterstadt DEUTSCHLAND

Die zusotzlich auch noch vorhandene Londerkennung unter dem Ort wird ebenfalls ent- fernt und angemerkt.

Der Ortsname soll per Definition aus nicht mehr als vier Wortern bestehen:

Max Mustermann Musterstrasse 35 O-03789 Frankfurt an der Oder

Hier ist der Ortsname noch gultig. Die Worter des Ortes durfen durch Leerzeichen oder Bindestrich voneinander getrennt sein.

Auch Strafiennamen bestehen aus bis zu vier Wortern und konnen durch Leerzeichen oder Bindestriche getrennt sein. Dem Strafiennamen folgt eine Zahl mit bis zu vier Ziffern und optional ein Buchstabe. Um den einzelnen Buchstaben der Hausnummer nicht als Wort zu identifizieren wird die Lange der moglichen Worter auf mindestens zwei Zeichen fest- gelegt. Damit sind bei weitem noch nicht alle moglichen Schreibweisen fur Strafiennamen abgedeckt. Nicht erkannt wird z.B. folgende Strafie:

Max Mustermann Musterstrasse 35-37 53789 Musterstadt

Den Namen einer Standardadresse sicher zu extrahieren ist eine grofie Herausforderung. Bei folgender Adresse treten Unstimmigkeiten beim Namen und beim Strafiennamen auf:

Klaus Muller-Zahl und Karin Muller-Schulz An der griinen Trift 10876 Frankfurt an der Oder

Der Algorithmus ist noch nicht so weit entwickelt, dass er das Verbindungswort ’und’ er- kennt und entsprechend zwei Namen validiert. Zum Fehlerhinweis bezuglich des Namens fuhrt der Umstand, dass dort zwei mit ’-’-Zeichen getrennte Doppelnamen enthalten sind. Der Fehlerhinweis bezuoglich des Strafiennamens ist bedingt durch die fehlende Hausnum- mer.

[...]

Details

Seiten
62
Jahr
2011
ISBN (eBook)
9783656237624
ISBN (Buch)
9783656238935
Dateigröße
1.1 MB
Sprache
Deutsch
Katalognummer
v197561
Institution / Hochschule
Fachhochschule Südwestfalen; Abteilung Iserlohn
Note
1,0
Schlagworte
Informatik Angewandte Angewandte Informatik Groovy Java Adressen Adressenidentifizierung Event Based Architecture Ereignis basierte Architektur EBC

Autoren

Zurück

Titel: Adressenidentifizierung in Textumgebungen