Bachelorarbeit im Fachbereich Informatik · gramms liegt der Fragebogen blanko, also unausgefüllt...

Bachelorarbeitim Fachbereich Informatik

Optimierung und Erweiterung einerSoftware zur teilautomatisierten

Auswertung in der psychologischenDiagnostik

Marlo Häring

Erstgutachter: Dr. Axel Schmolitzky

Zweitgutachter: Prof. Dr. Heinz Züllighoven

September 2012

Inhaltsverzeichnis

1 Einleitung 3

2 Ausgangslage 52.1 Das Programm QValuate . . . . . . . . . . . . . . . . . . . . 52.2 Anwendungsprobleme bei QValuate . . . . . . . . . . . . . . 62.3 Anforderungen an den Fragebogen . . . . . . . . . . . . . . 7

3 Softwaretechnische Grundlagen 93.1 Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Re-Implementierung . . . . . . . . . . . . . . . . . . . . . . . 103.4 WAM-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Analyse und Bewertung des Prototypen 134.1 Benutzte Open-Source-Werkzeuge . . . . . . . . . . . . . . . 13

4.1.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2 ObjectAid . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.3 Unit Tests / JUnit . . . . . . . . . . . . . . . . . . . . 14

4.2 Beschreibung des Prototypen . . . . . . . . . . . . . . . . . 144.2.1 Umfang . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . 144.2.3 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Bewertung des Prototypen . . . . . . . . . . . . . . . . . . . 164.3.1 Umfang . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . 174.3.3 Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Umstrukturierung oder Re-Implementierung . . . . . . . . 18

5 Projektplanung und Entwicklungsprozess 215.1 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . 215.3 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.1 Iteration 1: Fehlerbehebung in der grafischen Be-nutzeroberfläche . . . . . . . . . . . . . . . . . . . . . 23

5.3.2 Iteration 2: Werkzeug zur Rasterbildung . . . . . . . 245.3.3 Iteration 3: Integration des Werkzeugs zur Rasterbil-

dung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Seite 1

5.3.4 Iteration 4: Werkzeug zur Nachbearbeitung der Aus-wertung . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3.5 Iteration 5: Optimierung der grafischen Benutzer-schnittstelle und Nutzererfahrung . . . . . . . . . . . 27

6 Vergleich Prototyp <-> Re-Implementierung 316.1 Rasterimplementierung . . . . . . . . . . . . . . . . . . . . . 316.2 Auswertungsalgorithmen . . . . . . . . . . . . . . . . . . . . 326.3 Sichtprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.5 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . 35

7 Architektur der Re-Implementierung 377.1 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.1 QValuateWerkzeug . . . . . . . . . . . . . . . . . . . 377.1.2 EvaluateWerkzeug . . . . . . . . . . . . . . . . . . . 37

7.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.2.1 PDFService . . . . . . . . . . . . . . . . . . . . . . . . 387.2.2 GridWritingService . . . . . . . . . . . . . . . . . . 38

7.3 Materialien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.3.1 ResizableGrid . . . . . . . . . . . . . . . . . . . . . 387.3.2 Pdffile . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.4 Fachwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.4.1 RowResult . . . . . . . . . . . . . . . . . . . . . . . . 40

8 Zusammenfassung und Ausblick 43

Seite 2

Einleitung

1 Einleitung

In der psychologischen Diagnostik werden sowohl im Rahmen der Anamneseals auch therapiebegleitend neben dem psychologischen Interview standardi-sierte und testmethodisch konstruierte Fragebögen zur Datenerhebung undErfolgsbewertung eingesetzt. Mit diesem Instrument lassen sich große Mengenpersonenbezogener Daten sammeln und für den psychodiagnostischen Prozesszuverlässig weiter verarbeiten. Darüber hinaus kommen normierte Fragebögenin vielen anderen Wissenschaften forschungsbegleitend für die Erlangung em-pirischer Ergebnisse zum Einsatz.

Neben herkömmlichen, gedruckten Fragebögen werden zunehmend auch com-puterunterstützte Fragebögen bereitgestellt. Diese digitalen Methoden sind inder Entwicklung zwar kostenintensiver, bieten allerdings in der späteren An-wendung diverse Vorteile. Verschiedene Datenkontrollen hinsichtlich falscheroder unvollständiger Eingaben und der Datentransfer sind einfacher und si-cherer durchführbar, da die erhobenen Daten direkt in eine Auswertungssoft-ware einlesbar sind. Die Auswertung gestaltet sich zudem deutlich zeitsparen-der.

Für die psychologische Diagnostik wurde vom Dipl. Psych. Ingmar Böschenvon der Fakultät für Erziehungswissenschaft, Psychologie und Bewegungswis-senschaft der Universität Hamburg – im Folgenden Auftraggeber genannt –das sogenannte “e-paper-pencil“-Verfahren entwickelt, das mittels skaliertenFragebögen elektronisch Daten erfasst und gleichzeitig dem papiergestütztenVerfahren am nächsten kommt. Hierbei werden die Fragen auf einem mobilenTouch Screen (Tablet-PC) mit Touch Pen beantwortet. Diese Methode reduziertnachweisbar die Vorbehalte gegenüber dem Einsatz von Technik bei der Be-antwortung der Fragen. Es kommt seltener zu verfälschten Antworten. [Bö09]

Zur teilautomatisierten Auswertung von Fragebögen wurde im Rahmen einerfrüheren Bachelorarbeit das Java-Programm QValuate von Dalja Kludt entwi-ckelt. Namentlich wurde es an die Software QSheet angelehnt, mit dem derFragebogen für die Umfrage vorbereitet wird [Klu12]. QValuate setzt ohne Me-dienbruch auf das Programm QSheet auf.

QValuate konnte den Anforderungen der Praxis nicht vollständig gerecht wer-den. Die Aufgabenstellung dieser Bachelorarbeit besteht darin, eine optimier-te Software anhand der vom Auftraggeber erstellten Mängelliste von QValuate

Seite 3

Einleitung

und seinen aus der praktischen Anwendung resultierenden Erweiterungswün-schen zu entwickeln.

Im ersten Teil der Arbeit wird die bestehende Software QValuate im Hinblickauf Funktionalität, Architektur und Quelltext analysiert, bewertet und an-schließend eine Entscheidung getroffen, ob eine Umstrukturierung oder Re-Implementierung der Software durchgeführt werden soll.

Der zweite Teil dokumentiert die praktische Planung und Umsetzung der Pro-grammentwicklung. Im Vordergrund steht dabei die Behebung von dokumen-tierten Programmfehlern. Im Zuge des Optimierungsprozesses werden weiteresinnvolle Funktionen implementiert.

Seite 4

Ausgangslage

2 Ausgangslage

In diesem Kapitel wird die bestehende Software QValuate – im Folgenden auchals Prototyp bezeichnet – kurz beschrieben, wobei auf die vom Auftraggeberformulierten Anwendungsprobleme näher eingegangen wird. Darüber hinauswerden die formalen und technischen Anforderungen an den Fragebogen er-läutert.

2.1 Das Programm QValuate

Das Programm QValuate wird in der digitalen Diagnostik zur teilautomatisier-ten Auswertung von ausgefüllten Fragebögen eingesetzt. Beim Start des Pro-gramms liegt der Fragebogen blanko, also unausgefüllt als Vorlage im PDF-Format vor.

Zur Vorbereitung wird mit der Maus von der linken oberen Ecke der tabella-risch skalierten Antworten einer Seite des Fragebogens ein Rechteck zur rech-ten unteren Ecke aufgezogen. Für dieses Rechteck erfolgt nach Aktivierung mitder rechten Maustaste die Eingabe für die Zeilen- und Spaltenanzahl. Durcheinen Klick auf den entsprechenden Button wird das Raster mit den einzelnenZeilen (Fragen) und Spalten (Antwortalternativen) erstellt. Pro Seite kann je-weils nur ein Raster angelegt werden; allerdings ist die Anzahl der Zeilen undSpalten für das spezifische Raster der jeweiligen Seite individuell einstellbar.Die einzelnen Zeilenhöhen und Spaltenbreiten ergeben sich rechnerisch ausder gleichmäßigen Verteilung: Gesamtlänge des Rasters durch Spaltenanzahl;Gesamthöhe des Rasters durch Zeilenanzahl.

Eine zweite Möglichkeit der Rasterbildung besteht darin, zunächst über dieerste Zelle (oben links) ein kleines Rechteck zu ziehen, dieses zu speichernund durch ein erneutes Ziehen der Maus nach unten rechts ein Raster überdie gesamte Tabelle zu expandieren. Die weiteren Zeilen und Spalten werdenin gleicher Größe wie das Ursprungsrechteck automatisch erstellt.

Nach den oben beschriebenen Vorbereitungen, können die Rasterinformatio-nen in einer Datei gespeichert werden, sodass die Vorlage nur einmal vorberei-tet werden muss.

Nach einer “e-paper-pencil“-Befragung liegen ausgefüllte Fragebögen ebenfallsim PDF-Format vor. Die auszuwertenden Fragebögen werden in einem moda-len Dialogfenster zur Durchführung der teilautomatisierten Analyse selektiert.

Seite 5

Ausgangslage

Abbildung 1: Ausgefüllter Fragebogen, der ausgewertet wurde und nun fürdie Sichtprüfung bereit ist

Im Anschluss an die Analyse muss das Ergebnis einer seitenweisen Sichtprü-fung unterzogen werden, wobei einzelne Antworterkennungen zu korrigierensind.

Für jede Frage (Zeile des Rasters) wird in einer Ergebnismatrix ein Textfelderzeugt, in dem die erkannte Spaltennummer der Antwort eingetragen ist. BeiÜbereinstimmung von Markierung und Spaltenerkennung ist nichts weiter zutun. Bei Abweichung kann das Textfeld der Sichtung entsprechend korrigiertwerden (siehe Abbildung 1).

Die Überprüfung aller Seiten nach der oben genannten Methode muss in ei-nem Zuge erfolgen, da QValuate an dieser Stelle keine Zwischenspeicherungzulässt. Abschließend kann das Gesamtergebnis als CSV-Datei zur Weiterver-arbeitung abgespeichert werden.

2.2 Anwendungsprobleme bei QValuate

Die praktische Anwendung von QValuate wurde im Rahmen einer psychodia-gnostischen Befragung vom Auftraggeber im Feldeinsatz erprobt. Dabei trateneinige Defizite der Software sowie Erweiterungswünsche zu Tage, die einen um-fangreicheren Einsatz erschwerten. Die wesentlichen Punkte werden im Fol-genden beschrieben:

• Es kann lediglich ein Raster pro Seite erstellt werden. Dadurch werdendie Variationsmöglichkeiten bei der Fragebogenkonzeption eingeschränkt,weil nur eine zusammenhängende Tabelle mit Ankreuzmöglichkeiten aufjeder Seite existieren darf.

Seite 6

Ausgangslage

• QValuate sieht keine Funktion vor, die Zeilenhöhen und Spaltenbreitenindividuell anzupassen. Wenn einzelne Fragen aufgrund der Länge ih-rer Formulierungen unterschiedlich viele Textzeilen beanspruchen, kanndas auf Gleichmäßigkeit ausgelegte Auswertungsraster nicht der benö-tigten Höhe entsprechend angepasst werden und es kommt zu Verschie-bungen zwischen Fragen und Raster, was die Auswertungsmöglichkeiteneinschränkt, wenn nicht sogar unmöglich macht.

• Der visuelle Abgleich der von den Befragten getätigten Markierungen mitden Erkennungen gemäß Ergebnismatrix erfordert hohe Konzentrationund gestaltet sich sehr zeitaufwändig. Darunter kann die Genauigkeitder Endergebnisse leiden.

Die oben genannten Mängel sowie Erweiterungswünsche finden sich auch imBugreport des Auftraggebers wieder (s. S. 22), der als Einstieg für diese Bache-lorarbeit diente.

2.3 Anforderungen an den Fragebogen

Der standardisierte, zur Messung von Eigenschaften konstruierte Fragebogenmuss bestimmten grafischen Gestaltungsregeln entsprechen. Voraussetzungsind geschlossene Fragen, die abgestufte, skalierte Antworten ermöglichen.Fragen und Antwortformate werden einheitlich formuliert und rasterförmig inTabellenform angeordnet. Das Vorgeben von skalierten Antwortalternativen istGrundvoraussetzung für das automatisierte Auswerten der Antworten.

Seite 7

Softwaretechnische Grundlagen

3 Softwaretechnische Grundlagen

Im Folgenden werden einige grundlegende, im Kontext zu meinem Projekt ste-hende Begriffe erläutert.

3.1 Prototyp

In der Softwareentwicklung wird ein lauffähiger Programmteil, der ausgewähl-te Aspekte realisiert, als Prototyp bezeichnet und dient als Basis für die Kom-munikation mit dem Anwender bzw. Auftraggeber. Mithilfe dieses (Zwischen-)Feedbacks ist es dem Entwickler möglich, Probleme frühzeitig zu erkennenund Änderungswünsche mit geringerem Aufwand, da die Entwicklung nochnicht abgeschlossen ist, einfließen zu lassen. [HL10, S. 166]

QValuate betreffend bestanden die Hauptanforderungen des Zielsystems in derVorbereitung der Fragebogenvorlage, der Auswertung der ausgefüllten Fra-gebögen mit anschließender Sichtungsprüfung und das anschließende Spei-chern des Endergebnisses in einer CSV-Datei.

Das vom Auftraggeber im Feldeinsatz erprobte Programm wies noch einigeMängel in den Grundfunktionalitäten auf, die in Form des oben bereits er-wähnten Bugreports kommuniziert wurden. Aufgrund der Definition im erstenAbsatz wird das bereits entwickelte Programm QValuate als Prototyp klassifi-ziert und im Folgenden so genannt.

3.2 Refactoring

Refactoring ist eine Methode in der Softwareentwicklung, die das Verständnisund die Strukturierung von Programmcode verbessern soll. Bei der Umstruk-turierung bzw. Überarbeitung geht es nicht darum, das beobachtbare Verhal-ten zu ändert. Refactoring soll immer als eigenständiger Prozess präventiv aus-geführt werden und nicht in direktem Zusammenhang mit der Erweiterung desProgramms um neue Funktionen oder Korrekturen aufgetretener Fehler ste-hen [HL10, S. 593]. Umstrukturierung vorhandenen Codes mit gleichzeitigerErgänzung um neue Funktionen gestaltet sich wesentlich komplexer, aufwän-diger, und damit schwieriger und fehleranfälliger. Refactoring ist also eine reineWartungsmaßnahme in Bezug auf den Programmcode, um das Programm ge-gebenenfalls anschließend leichter, mit weniger Aufwand erweitern zu können.Nach Fowler steht unter Anderem die Performance-Optimierung im Gegensatzzum Refactoring. Zwar ändert sie – außer in Bezug auf die Ablaufgeschwindig-

Seite 9


keit des Programs – ebenfalls nicht das sichtbare Verhalten, jedoch macht dieseArt des Eingriffs den Quellcode vom Verständnis her komplizierter [MF99, S.47]. Im Folgenden wird Refactoring mit dem Begriff Umstrukturierung über-setzt.

3.3 Re-Implementierung

Im Gegensatz zur Umstrukturierung von Programmcode wird häufig auch ei-ne Re-Implementierung als Option ins Auge gefasst. Dabei handelt es sich umdie völlige Neu-Implementierung der bestehenden Software-Funktionalitäten.Anders als bei der Umstrukturierung kann sich hier auch das beobachtbareVerhalten ändern. Bei der Re-Implementierung wird nicht vom bestehendenQuellcode ausgegangen; es kann von Grund auf neu entwickelt werden. Dieneu zu entwickelnde Softwarearchitektur kann einem völlig anderen Konstruk-tionsansatz zugrunde liegen als die “alte“ Implementierung.

3.4 WAM-Ansatz

Der “Werkzeug & Materialansatz“ (WAM-Ansatz) ist eine Methode der objekt-orientierten Software-Entwicklung, die auf Anwendungsorientierung und ho-he Gebrauchsqualität ausgerichtet ist. Damit eine Software optimal eingesetztwerden kann, muss sich das Softwareprojekt in der Entwicklungsphase andem Anwendungsgebiet orientieren, in dem die Software eingesetzt werden soll.Dabei werden verschiedene Metaphern benutzt, um die Gegenstände des An-wendungsgebiets auf das Benutzungsmodell der Software abzubilden. Bei denMetaphern handelt es sich hauptsächlich um folgende:

• Werkzeuge verändern oder sondieren Materialien. Sie werden in wech-selnden Kontexten für verschiedene Materialien benutzt. Das Bild vonWerkzeugen lässt sich auch auf softwaretechnische Werkzeuge übertra-gen. In Softwareprodukten, die nach dem WAM-Ansatz entwickelt wur-den, hat der Benutzer eine Sammlung von Software-Werkzeugen zur Ver-fügung, mit denen er die Materialien zum Arbeitsergebnis formen kann.[Zü98, S. 83f.]

• Das Material wird am Ende der Bearbeitung mit Werkzeugen oder Auto-maten Teil des Arbeitsergebnisses. Voraussetzung dafür ist, dass die ein-gesetzten Materialien jeweils für eine Bearbeitung geeignet sind. Bei Ma-terialien lassen sich ihre Eigenschaften aus der Anwendungswelt leichtauf die Materialien in der Softwareentwicklung abbilden. [Zü98, S. 85f.]

Seite 10


• Automaten übernehmen sich ständig wiederholende, zeitraubende Routi-nearbeiten bei der Bearbeitung der Materialien. Der entsprechende Vor-gang wird einmalig gestartet, läuft dann im Hintergrund und liefert ohneweitere äußere Eingriffe abschließend ein Ergebnis. [Zü98, S. 88f.]

• Bei Behältern handelt es sich im weitesten Sinne um Materialien, dieebenfalls von Werkzeugen bearbeitet werden. Behälter können jedoch wei-tere, verschiedenartige Materialien beinhalten, und zwar entweder belie-big viele oder eine feste Anzahl verschiedener Materialien, die sie aufneh-men und herausgeben können. [Zü98, S. 89f.]

Entwicklern, die den WAM-Ansatz kennen, fällt es deutlich leichter, sich ineine bestehende, zu pflegende oder zu optimierende Software einzuarbeiten,die nach ihm konzipiert wurde.

Seite 11

Analyse und Bewertung des Prototypen

4 Analyse und Bewertung des Prototypen

Ziel der Analyse war es eine Entscheidung darüber zu treffen, ob der vor-liegende Quellcode umstrukturiert werden sollte, oder ob für eine optimierteFunktionalität eine Reimplementierung effizienter wäre (siehe Abschnitt 3.3).Voraussetzung für die Entscheidungsfindung war eine detaillierte Betrachtungdes Aufbaus und Umfangs des Quellcodes.

4.1 Benutzte Open-Source-Werkzeuge

Im Folgenden werden die Werkzeuge für die Analyse des Prototypen vorgestellt.Sie sollen die bestehende Architektur quantitativ charakterisieren um diesedadurch besser bewerten zu können. Die Interpretation von Metriken setzthäufig Vergleichswerte voraus, die aber nicht immer vorliegen, wodurch dieNützlichkeit gemindert wird. Außerdem sollten Metriken eher als Indikator fürqualitativ mangelhaften Quelltext herangezogen werden und nicht als ein Belegfür gut verständlichen Quelltext benutzt werden.[Sta09, S. 316f.]

4.1.1 Metrics

Das Plugin Metrics für die Entwicklungsumgebung Eclipse ist in der Lage eineganze Reihe an Metriken für den bestehenden Quellcode zu berechnen. Darun-ter fallen Anzahl von Klassen, Methoden und Quelltextzeilen, sowie Verhältnis-se zwischen diesen Werten. Außerdem werden weitere Werte nach bestimmtenFormeln errechnet wie beispielsweise Afferent Coupling. Dabei handelt es sichum eine Kennzahl für ein Paket, das die Anzahl der Klassen außerhalb des Pa-ketes zählt, die sich auf Klassen innerhalb des Paketes beziehen. Werte, die Me-trics als problematisch beurteilt, werden in der Problemansicht angezeigt. Aufdiese Weise können die Benutzer den Zustand des Quelltextes ständig überwa-chen. Die berechneten Ergebnisse lassen sich dann als HTML, CSV oder XMLDatei für weitere Analysen exportieren. Die Informationen der in dieser Arbeiteingefügten Tabellen wurden mit diesem Plugin erstellt. [SOF12]

4.1.2 ObjectAid

ObjectAid ist ebenfalls ein Plugin für die Entiwcklungsumgebung Eclipse. Esist ein UML-Tool, dass dem Entwickler hilft den Überblick über die Architek-tur des Projektes zu bewahren. Dabei wird der Quelltext analysiert und Bezie-hungen festgestellt, wodurch abschließend ein UML Diagramm auf Klassen-oder Paketebene erstellt werden kann. Die Detailtiefe der Diagramme kann da-

Seite 13


bei vom Benutzer angepasst werden, indem beispielsweise Exemplarvariablenoder Signaturen der Klassen ein- und ausgeblendet werden können. [LLC12]

4.1.3 Unit Tests / JUnit

Bei Unit Tests geht es darum, einzelne Bestandteile des gesamten Systems zuüberprüfen. In objektorientierten Sprachen, bildet ein Bestandteil eine Klasse.Außerdem lassen sich diese Tests zeiteffektiv automatisiert durchführen undsind damit gründlicher als manuelle Tests. Gerade beim Umstrukturierungs-prozess des Quelltexts ist es notwendig die Funktionalität des Programmsnach jeder kleinen Änderung zu testen, damit sich keine Fehler einschlei-chen [Men12, S. 8f.]. Grundsätzlich sollte die Erstellung von Testfällen zumEntwicklungsprozess gehören. Der Aufwand für eine Fehlerberichtigung steigtexponentiell mit der Anzahl der Entwicklungsphasen, die seit dem Entstehendes Fehlers vergangen sind. Daher sollte die Fehlerkorrektur bei gefundenenFehlern immer sofort durchgeführt und nicht aufgeschoben werden. [Sta09,S.180 f.]

Für Java wurde das Open-Source Testframework JUnit von Beck und Gammaentwickelt. Die aktuelle Version steht auf sourceforge1 zum Download zur Ver-fügung. Das Framework ist ebenfalls in Java geschrieben. Außerdem lässt sichjeder Test in eine eigene Testklasse auslagern, wodurch sich die Organisationvon Tests im bestehenden Quelltext übersichtlich gestaltet.

4.2 Beschreibung des Prototypen

4.2.1 Umfang

Die Tabelle 1 wurde mit dem Eclipseplugin Metrics erstellt und zeigt einigeKennzahlen des Prototypen. In der Tabelle wird das Gesamtsystem als Ganzes,sowie in einer Unterteilung auf Paketebene betrachtet. Wie aus der Tabelleersichtlich besteht der Prototyp aus vier Paketen mit insgesamt elf Klassen, dieinsgesamt für ihre 2319 Anweisungen 112 Methoden füllen. Die angegebenenKennzahlen sind nur eine Auswahl aller berechneten Werte.

4.2.2 Architektur

Der Prototyp wurde in der ersten Version mit der Entwicklungsumgebung Net-beans von Oracle entwickelt und benutzt als grafische Benutzerschnittstelledie Swing Bibliothek. Der Prototyp besteht aus elf Klassen und benutzt für die

1http://www.sourceforge.net/

Seite 14


Gesamt evaluation matrix qvaluate utilsPakete 4 - - - -

Klassen 11 3 2 2 4Anweisungen 2319 752 405 699 463

Methodenanzahl 112 28 31 27 31Anweisungen pro Methode 20,71 26,86 13,06 25,89 14,94

Methoden pro Klasse 10,18 9,33 15,50 13,5 7,75Afferent Coupling (Ca) - 1 4 8 4

Tabelle 1: Metriken des Prototypen (erstellt mit dem Eclipse-Plugin Metrics)

Verarbeitung der PDF Dateien die externe Bibliothek JPedal [IDR12]. Das Pro-gramm ist in vier Pakete gegliedert: qvaluate, matrix, evaluation und utils.

qvaluate

Dieses Paket enthält die Hauptklasse QValuateApp, die das Programm startet.Die komplette grafische Benutzerschnittstelle (Buttons, Eingabefelder, Menü-leisten und weitere Komponenten) mit der dazugehörigen Funktionalität ist inder Klasse QValuateView implementiert. Der Code, der die grafischen Kompo-nenten initialisiert und anordnet, wurde von dem Netbeans Editor für grafischeBenutzerschnittstellen (GUI-Builder) erstellt. [Klu12]

matrix

Die Hauptfunktionalität dieses Pakets besteht in dem Zeichnen der Raster, umdie Fragebogenvorlage vorzubereiten. Es besteht aus zwei Klassen. Die KlassePageView behandelt das Erstellen der Raster und die gleichmäßige Aufteilungdes Rasters, per drag and drop, in die angegebene Anzahl an Zeilen und Spal-ten. Die Klasse PageManager speichert die Rasterinformationen in eine Datei,sodass die Vorlage nicht erneut für jede Auswertung vorbereitet werden muss.Neue Raster werden einer Liste zugefügt. Die Raster lassen sich in eine Dateispeichern, da das Interface Serializable implementiert wurde. [Klu12]

evaluation

Dieses Paket beinhaltet drei Klassen und behandelt die Auswertung der aus-gefüllten PDF-Fragebögen. Die Klasse Evaluation ist für die Auswertung zu-ständig, worunter Bildverarbeitung, Pixelzählungen und Interpretation der Er-gebnisse zählen. Die Klasse ResultDialogView übernimmt das Speichern derErgebnisse in einer CSV-Datei und stellt die erkannten Ergebnisse farbig da.ViewPdfPage ist für die Anzeige der aktuellen PDF Seite zuständig. [Klu12]

Seite 15


utilsDieses Paket enthält vier Klassen, darunter eine Klasse, die für die Darstel-lung der Aboutbox zuständig ist. Außerdem die Klasse PDFManager, die dieFragebogenvorlage lädt, durch sie blättert und schließt. Dabei wird die Biblio-thek JPedal verwendet, um die Seiten der Datei in Bilder umzuwandeln undanzuzeigen. Die Klasse Preview verwaltet die Miniaturbilder der Seiten in derlinken Scrollleiste. Außerdem enthält das Paket eine Klasse, die als Filter fürdie Dateiauswahl dient, da nur PDF Dateien geöffnet werden können, sind nurdiese in der Dateiauswahl sichtbar. [Klu12]

4.2.3 Quellcode

Der Prototyp von QValuate wurde mit Netbeans entwickelt um von dem in-tegrierten Swing GUI Builder Gebrauch zu machen. Der GUI-Editor stellt einkomfortables Werkzeug da, um das Benutzerinterface in kurzer Zeit zu erstel-len. Zusätzlich bekommt der Entwickler beim Erstellen schon einen Einblickdavon, wie es letztendlich in der Anwendung aussehen wird („What you see iswhat you get“). Die einzelnen Komponenten werden dazu per drag and dropleicht positioniert und mit einem weiteren Werkzeug können die Eigenschaftender Komponenten zusätzlich angepasst werden. Die Erstellung einer robustenGUI in Java stellt sich häufig als kompliziert und zeitaufwändig heraus, dadie möglichen Layoutmanager umfangreiche Einstellungsmöglichkeiten bietenund aufeinander abgestimmt werden müssen. Das macht die Nutzung einesBuilders reizvoll.

Der GUI-Builder bietet die Funktionalität, durch das Klicken auf Komponen-ten automatisiert das Codegerüst erstellen zu lassen, um die betreffende Kom-ponente mit Aktionscode zu versehen. Um dies zu realisieren legt Netbeansselbstständig eine actionMap an, in der zu einem String der dazugehörendeMethodenname abgefragt werden kann. Diese wird dann ausgeführt, wenn dieentsprechende Aktion eintritt.

4.3 Bewertung des Prototypen

4.3.1 Umfang

Bei der Betrachtung der tabellarischen Auswertung wird deutlich, dass derUmfang des Programmcodes einem Maß entspricht, das ein Entwickler ausrei-chend überschauen und warten kann. Drei Monate sollten dabei ausreichen,um eine Re-Implementierung des Prototypen durchzuführen. Dennoch sollten

Seite 16


Abbildung 2: Paketstruktur von QValuate (Prototyp)

die Zahlen nicht ausschließlich als Maß herangezogen werden, da beispiels-weise schon durch Codeformatierung die Anzahl der Codezeilen bis zu einemFaktor von drei variieren können. Eine geringe Anzahl an Codezeilen muss keinIndiz für ein leicht überschaubares Programm sein, da externe Bibliothekenbenutzt werden können, oder es sich um einen schlecht lesbaren Code han-delt. Daher kann es bei gleicher Funktionalität durch eine bessere Lesbarkeitzu einer erhöhten Anzahl an Codezeilen kommen, was die Wartung erleichtert,aber ein verfälschtes Bild der Komplexität zeigt. [Hum11, S. 35f.]

4.3.2 Architektur

Bei der Betrachtung des UML Diagramms auf Paketebene (Abbildung 2) istauffallend, dass sogar mehrere zyklische Referenzen zwischen den Paketenbestehen. Diese Beziehungen führen zu einer besonders starken Kopplung dervier Pakete. Dies lässt sich ebenfalls anhand des Ca quantifizieren. Bei derMetrik wird die Anzahl der Klassen außerhalb eines Paketes, die eine Referenzauf eine Klasse innerhalb des Paketes halten und damit abhängig davon sind,betrachtet (siehe Tabelle 1). Bei den bevorstehenden Erweiterungen und Op-timierungen der Software sollte der Algorithmus für die Evaluation der Mar-kierungen unabhängig von der grafischen Benutzerschnittstelle überarbeitetwerden können. Gleiches gilt für die Erstellung der Raster. Die Architekturdieses Prototypen macht diese unabhängigen Erweiterungen unmöglich ohnemehrere Pakete parallel zu bearbeiten. Während dieser Eingriffe können vieleFehler entstehen.

4.3.3 Quellcode

Für das Verständnis des Quelltextes ist es wesentlich, dass durch Kommenta-re die Zuordnung der Klassen entsprechend ihrer Zuständigkeiten erkennbar

Seite 17


ist. Bei fehlenden Kommentaren, wie im vorliegenden Quelltext des Prototypen,mussten die Methodenimplementierungen und Exemplarvariablen zeitintensivim Einzelnen betrachtet werden, um einen Gesamtüberblick über die Zustän-digkeiten der Klassen zu erhalten.

Ein weiterer wesentlicher Nachteil ist die mangelnde Lesbarkeit des automa-tisiert erzeugten Codes durch den GUI Builder. Der Builder von Netbeans be-nutzt das GroupLayout [Cor12], das extra für GUI Builder konstruiert wurde.Durch die Verwendung von Netbeans wird zwingend eine Richtlinie für die Ar-chitektur der Klassen vorgegeben, die sich im gesamten Projekt verwurzelt. DieKlasse QValuateView im Prototyp ist sehr umfangreich geworden, da die In-itialisierungen der GUI-Elemente, sowie die Methoden für die Aktionsbehand-lung der Komponenten in dieser Klasse vorgenommen werden.

Sollte im Rahmen einer Umstrukturierung eine andere Softwarearchitekturverwendet werden, müssten tiefgreifende Änderungen in der Quelltextstruk-tur vorgenommen werden. Infolgedessen könnte anschließend der starre GUI-Builder von Netbeans nicht mehr verwendet werden, da er die entstandeneArchitektur nicht mehr parsen kann. Dadurch wäre eine Abhängigkeit vonNetbeans aufgehoben und jede andere Entwicklungsumgebung wäre ebenfallsgeeignet.

4.4 Umstrukturierung oder Re-Implementierung

Für die vorgegebene Aufgabenstellung musste nunmehr eine Entscheidungüber das weitere Vorgehen getroffen werden. Dabei stellte sich die Frage ob dervorhandene Quelltext umstrukturiert oder neu implementiert werden sollte.Bei einer Re-Implementierung könnte die Architektur von Grund auf nach derbewährten Entwicklungsmethode WAM auf konstruiert werden. Dabei werdendie folgenden Argumente aufgelistet und gegeneinander abgewogen um eineEntscheidung für den weiteren Verlauf des Projektes zu treffen.

Umstrukturierung

• Eine Umstrukturierung kann in kleineren, für sich abgeschlossenen Teil-schritten erfolgen. Die Gesamtsoftware bleibt in ihrem Funktionsumfangstets lauffähig. Insgesamt wird die Struktur, die Lesbarkeit und damit dieQualität verbessert. Bei einer Re-Implementierung muss der Quellcode ineinem Stück soweit fertiggestellt werden, dass der alte Funktionsumfangwieder nahezu hergestellt ist. Das Risiko einer Fehleinschätzung bei ei-

Seite 18


ner Re-Implementierung in Bezug auf den zeitlichen Aufwand ist weitaushöher.

Re-Implementierung

• Aufgrund des schwer lesbaren, wenig strukturierten Quelltextes wür-de sich eine tiefgründige Einarbeitung sehr zeitaufwendig gestalten, waseher für eine Re-Implementierung sprechen würde.

• Bei der Re-Implementierung kann nach dem bewährten WAM-Ansatz vonGrund auf neu entwickelt werden um eine bessere Software-Architekturzu gewährleisten. Trotzdem können Teile des bestehenden Codes über-nommen werden oder als Vorlage dienen.

• Der Prototyp enthält keine Testklassen, die eine Umstrukturierung nachjedem Schritt absichern würden. Testklassen sind eine Grundvorausset-zung für eine Umstrukturierung (siehe Abschnitt 4.1.3). Setzt der Ent-wickler hingegen auf ein System auf und beginnt im Laufe der Umstruk-turierung Testklassen zu erstellen, besteht die Gefahr, dass dabei unge-wünschtes Verhalten in Tests festgeschrieben wird. [Men12, S. 344 f.]

• Die Bewertung des Quelltextes mithilfe der Metriken ergab, dass die Zeit-vorgabe der Projektarbeit aufgrund des relativ geringen Umfangs des Pro-totypen eine Re-Implementierung zulassen würde.

• Nach Definition können die diversen Fehler bzw. Erweiterungen nur imRahmen einer Re-Implementierung behoben bzw. integriert werden (sieheAbschnitt 3.3).

Nach Abwägung der oben angeführten Argumente fiel die Entscheidung zu-gunsten einer Re-Implementierung aus. Ausschlaggebend waren insbesondereder WAM-Ansatz und die Implementierung der Erweiterungswünsche.

Seite 19

Projektplanung und Entwicklungsprozess

5 Projektplanung und Entwicklungsprozess

In diesem Kapitel wird die Vorgehensweise und schrittweise Entwicklung desProjektes vorgestellt.

5.1 Vorgehensmodell

Um den komplexen Prozess der Re-Implementierung zu strukturieren, fiel dieEntscheidung für ein “agiles“ Vorgehen und gegen das Wasserfallmodell . Letz-teres zeichnet sich durch seinen sequentiellen Charakter aus. Bei dieser Me-thode müssen alle Vorgaben an das Projekt bereits zu Beginn vorliegen undder gesamte Projektablauf wird in Phasen aufgeteilt. Eine Rückkehr in vorher-gehende Phasen ist nur mit viel Aufwand möglich.

Zu Beginn dieses Projektes waren noch nicht alle fachlich und technischenAnforderungen bekannt, sodass es im Zuge der Entwicklung häufig zu Ände-rungen und Erweiterungen kommen konnte. Als Garant für den Projekterfolgwurde gemäß dem flexiblen agilen Vorgehen die rege Kommunikation mit demAuftraggeber erachtet, damit gezielt auf dessen Wünsche eingegangen und dasFeedback eingearbeitet werden konnte. Dieser zyklische Entwicklungsprozesshalf, eine realistische Vorstellung über die tatsächliche Entwicklungsgeschwin-digkeit zu bekommen.

Die Entwicklung des Projekts wurde in mehrere Iterationen gegliedert. JederIteration folgte ein Treffen mit dem Auftraggeber um jeweils anhand einer lauf-fähigen Version die Fortschritte zu präsentieren. Außerdem ermöglichte derDialog auch eigene Erweiterungsideen in den Entwicklungsprozess einfließenzu lassen.

5.2 Versionsverwaltung

Bei der Entwicklung der Re-Implementierung wurde das kostenfreie Version-verwaltungswerkzeug des Onlineanbieters sourceforge.net benutzt. Auf diesemWege wurde ein Repository angelegt, sodass bequem von mehreren Computernentwickelt werden konnte und jederzeit überall der aktuelle Stand des Quell-codes zur Verfügung stand.

Die einzige Voraussetzung ist eine installierte Version einer geeigneten Ent-wicklungsumgebung und ein Plugin-in für den Zugriff auf ein SVN Zugriff,sowie eine installierte Version des Java Development Kit, um den aktuellsten

Seite 21


Stand des Quellcodes herunterzuladen und zu kompilieren. Für dieses Projektwurde die Entwicklungsumgebung Eclipse mit dem Plugin Subclipse entwi-ckelt.

Ein weiterer Vorteil ergab sich durch die Kommentierung beim Hochladen vonQuelltextänderungen, da sich diese am Ende beim Rekonstruieren des Vor-gehens als äußerst hilfreich erwiesen. Darüber hinaus konnte jeder Entwick-lungsstand der Software reproduziert werden. Das Hoch- und Runterladen derÄnderungen am Quelltext sind durch das Plugin Subclipse komfortabel inte-griert und lassen sich aus Eclipse heraus vornehmen. [Col12]

Der agile Entwicklungsprozess gliederte sich in fünf iterativen Entwicklungs-phasen. Zum Abschluss jeder Iteration wurde das Zwischenergebnis dem Auf-traggeber vorgestellt, da die Software später praxisbezogen von ihm eingesetztwerden sollte. Jede einzelne Iteration enthielt einen Planungs-, Umsetzungs-und Präsentationsteil. Feedback wurde bei der darauffolgenden Iteration inte-griert. Als Einstieg in die Entwicklung wurde der folgende vom Auftraggebervorgelegte Bugreport herangezogen und kategorisiert:

Änderungen an der grafischen Benutzerschnittstelle

• Im Menü “File“ kann der Menüpunkt “Open file for Analyse“ entfernt wer-den

• Im Menü “File“ soll der der Menüpunkt “Open Files for Analyse“ zu “Eva-luate Files“ umbenannt werden

• Der Button zum Vorblättern soll von “...“ zu “»“ geändert werden

• Seitennummer der aktuell dargestellten Seite anzeigen

• Den Buttontext “Evaluate“ zu “Select Files“ umbenennen

• Beim Öffnen des Matrizen- und Auswertungsprogramms das jeweiligeFenster auf Vollbild skalieren

• Beim horizontalen Verkleinern des Fensters wird der horizontale Scroll-balken der Seitenvorschau nicht benutzt, sondern es verschwinden Kom-ponenten, sodass diese bei einer zu geringen Fenstergöße oder bei zukleiner Auflösung nicht mehr anklickbar sind

Seite 22


Algorithmus für die Erkennung der Markierung

• Der bestehende Algorithmus (mindestens 1% Pixel) funktioniert nicht beigroßen Feldern

Rastererstellung

• Mehrere Rasterkonstruktionen pro Seite ermöglichen

• Spaltenbreite und Zeilenhöhe der Raster per drag and drop nachjustierenkönnen

Auswertungsfenster

• Farbige oder farbig-transparente Hinterlegung des erkannten Feldes

• Seiten ohne Raster brauchen bei Sichtungsprüfung nicht angezeigt wer-den

5.3 Iterationen

5.3.1 Iteration 1: Fehlerbehebung in der grafischen Benutzeroberfläche

Zu Beginn der 1. Iteration wurde hauptsächlich auf die in der Kategorie “Än-derungen an der grafischen Benutzerschnittstelle“ aufgeführten Mängel einge-gangen. Darunter fielen einfache, noch durch den GUI-Builder von Netbeans,behebbare Korrekturen. Die Änderungen der Labels von Menüpunkten undButtons ließen sich damit problemlos beheben, da der GUI-Builder eine zwei-spaltige Tabelle zur Verfügung stellt, in der die einzelnen Eigenschaften dermarkierten Komponente übersichtlich aufgeführt werden. In der rechten Spal-te können die Eigenschaften mit entsprechenden Werten gesetzt werden. EinHauptproblem besteht darin, dass bei horizontaler Verkleinerung des Haupt-fensters wichtige Komponenten für die Interaktion nicht mehr angezeigt wer-den. Die Größeneinstellungen von der Scrollpanelkomponenten für die Seiten-ansicht sind nicht korrekt justiert. Bei Computern mit ausreichender Pixe-lanzahl in der Horizontalen besteht dabei kein Problem, wohingegen sich dasProgramm bei Computern mit geringer Auflösung nur umständlich bedienenlässt. Durch passende Wertänderungen bei den Größeneinstellungen der Pa-nelkomponenten waren alle Komponenten bei jeder Fenstergröße nutzbar.

Nach diesen überschaubaren Änderungen ergab das Feedback vom Auftrag-geber, dass die grafische Benutzerschnittstelle noch Komponenten enthielt dieim weiteren Verlauf des Projektes diskutiert werden sollten.

Seite 23


5.3.2 Iteration 2: Werkzeug zur Rasterbildung

Nach der 1. Iteration konnte auf den sehr starren GUI-Builder verzichtet wer-den, sodass eine Portierung des Projektes in die Entwicklungsumgebung Eclip-se durchgeführt werden konnte. Die Entscheidung fiel auf Eclipse, da der Um-gang mit dieser führenden Software geläufig war.

Außerdem war es nicht möglich, den WAM-Ansatz effektiv mit dem GUI-Builderzu koppeln, da der Builder, wie in Abschnitt 4.3.3 beschrieben, eine sehr strik-te Behandlung für Aktionen vorsieht.

Für die Portierung wurde der Prototyp angefangen bei der Klasse QValuateView,gemäß des Musters Trennung von Interaktion und Funktion, in zwei Komponen-ten unterteilt:

InteraktionDie Interaktion einer Software wird oftmals durch eine grafische Benutzer-schnittstelle realisiert. Es stellt die Art und Weise der Handhabung und dieForm der Präsentation von Werkzeugen dar. [Zü98, S. 238]

FunktionDie Funktion beschreibt die fachliche Funktionalität eines Werkzeugs. DieseKomponente ist letztlich dafür da um die Materialien zu bearbeiten und son-dierende Operationen durchzuführen. [Zü98, S. 234ff.]

Die Architektur des Prototypen beinhaltet die Klasse QValuateView, die derGUI-Builder für die Bearbeitung der PDF-Vorlage erstellte, in der die Interak-tionskomponenten [Zü98, S. 238], sowie die Funktionskomponenten [Zü98, S.240] zusammen implementiert wurden. Benötigt wurde ein Werkzeug für dieBearbeitung der PDF-Vorlagen, sodass die Klasse QValuateView ersetzt wer-den konnte. Dieses Werkzeug setzt sich aus den zwei Klassen QValuateUI undQValuateWerkzeug zusammen. QValuateUI repräsentiert die Benutzung desWerkzeugs für den Anwender durch die grafische Benutzerschnittstelle (Inter-aktionskomponente) und wird von der Klasse QValuateWerkzeug referenziertund verwaltet, die die Funktionalität (Funktionskomponente) des Werkzeugsimplementiert (siehe Abbildung 10 auf S. 39). Durch diese Aufteilung konn-te der generierte Quellcode des GUI-Builders vorerst wiederverwendet werden.Darüber hinaus wurde zur Konstruktion der Klassen das Muster Extract class[MF99, S. 122] als Leitlinie verwendet. Die Fragebögen müssen als “Material“vom QValuateWerkzeug bearbeitet und vorbereitet werden. Daher wurde die

Seite 24


vorhandene Klasse PDFDecoder aus dem externen Framework JPedal [IDR12]benutzt, um eine PDF-Datei als Material in der Architektur zu repräsentieren.

Der PDFDecoder ermöglicht zahlreiche sondierende und verändernde Zugriffeauf PDF-Dateien. Die Rasterspeicherung auf den Seiten der Fragebogenvor-lage setzten jedoch individuelle Anpassungen der Klasse voraus, sodass dieMaterialklasse Pdffile die Klasse PDFDecoder erweitert und auf die erwei-terten Bedürfnisse zugeschnitten werden konnte. Die Entwicklung der KlassePdffile wurde so umgesetzt, dass ein Exemplar der Klasse entweder eine Fra-gebogenvorlage oder eine ausgefüllte PDF-Datei repräsentieren kann.

Demonstration des veränderbaren RastersUm die Erstellung des Rasters auf die Anforderungen, die durch die Fragebö-gen vorgegeben wurden, anzupassen, wurde ein Prototyp in einer separatenAnwendung ausschließlich für die Rastererstellung entwickelt. Dies dient da-zu, die Funktionalität vorerst isoliert zu implementieren und zu präsentieren,ohne sie vollständig in das bestehende System zu integrieren. Eine vorzeiti-ge Integration in das Gesamtsystem würde erhöhten Zeitaufwand bedeuten.Außerdem kann die Handhabung und Tauglichkeit des Werkzeugs vorher be-urteilt werden. Der Prototyp besteht aus einem JFrame, der die Erstellungeines Rasters mit festgesetzter Anzahl von Zeilen und Spalten per drag anddrop erlaubt. Nachträglich lassen sich die Zeilenhöhen und Spaltenbreiten je-weils voneinander unabhängig anpassen. Als Vorlage diente die insbesondereaus Excel bekannte Möglichkeit der Zeilen- und Spaltenanpassung per dragand drop. Der Prototyp erfüllte die gegebenen Anforderungen und konnte inder folgenden Iteration in die Re-Implementierung integriert werden.

5.3.3 Iteration 3: Integration des Werkzeugs zur Rasterbildung

Bei der Implementierung der veränderbaren Raster wurde die Klasse Pdffile,nach dem Werkzeug & Material Ansatz, als Behälter [Zü98, S. 188ff.] ange-sehen, der eine Sammlung von Materialien enthält. In diesem Fall bestanddie Sammlung ausschließlich aus veränderbaren Rastern (ResizableGrid).Sie werden in der PDF-Datei verwaltet und Seitenweise angeordnet. Zusätzlichlässt sich der Zustand dieses Behälters in eine Datei Speichern, da die Klas-se ResizableGrid das Interface Serializable implementiert, wodurch derBehälter ebenfalls transportfähig wird und von verschiedenen Orten aus ko-operativ bearbeitet werden kann. Am Ende dieser Iteration waren alle Punkteder Liste unter der Kategorie Rastererstellung vollständig implementiert.

Seite 25


5.3.4 Iteration 4: Werkzeug zur Nachbearbeitung der Auswertung

Die Planung der vierten Iteration bestand im Wesentlichen aus der Konzeptioneines Werkzeugs für die Sichtprüfung.

In der Prototypversion wurde diese Aufgabe von der Klasse ResultDialogViewübernommen, die ebenfalls von dem GUI-Builder organisiert wurde. Diese Klas-se musste ebenfalls in ein Werkzeug gegossen werden, sodass eine Klasse fürdie Interaktions- und eine weitere für die Funktionskomponente entstehen.

Parallel dazu wurde ein geeigneter Algorithmus entworfen, der die korrekteSpaltenmarkierung zu den einzelnen Fragen findet. Der entstandene Algorith-mus basierte angelehnt an den Prototypen und berechnet vorerst die Differenz-bilder von den ausgefüllten Fragebögen und der Fragebogenvorlage [Klu12].Anschließend können mit den Rasterkoordinaten, die durch die vorhergehendeSpeicherung bekannt sind, die nicht-schwarzen Pixel gezählt und den einzel-nen Zellen zugeordnet werden. Anfangs galt die Spalte als markiert, in der dieAnzahl der nicht-schwarzen Pixel am höchsten war. Diese erste Testimplemen-tierung des Algorithmus wurde im weiteren Verlauf des Projektes durch eineerweiterte Variante abgelöst.

Funktionsweise des AlgorithmusDie von den Befragten händisch getätigten Markierungen wiesen bei der Analy-se eine hohe Diversität auf, sodass sich die Entwicklung des Algorithmus zurAuswertung als aufwändig erwies. Es galt also, einen Algorithmus zu entwi-ckeln, der dieser Vielfältigkeit gerecht wurde.

Der entwickelte Algorithmus zur Erkennung der Markierung arbeitet mit derAnzahl der nicht-schwarzen Pixel, die entstehen, nachdem die einzelnen Pixel-werte der Fragebogenvorlage von dem ausgefüllte Fragebogen subtrahiert wer-den. Durch die Rasterinformationen kann jeder Zelle eine bestimmte Anzahlder nicht-schwarzen Pixel zugeordnet werden, die zur weiteren Interpretationgenutzt werden.

Damit die verschiedenen Zustände einer Zeile erkannt werden können, werdenbei der Zählung folgende Informationen gesammelt:

A Anzahl der Zellen pro Zeile, in der mindestens 4% (relativ zur Zellengröße)der Pixel markiert sind (Anzahl der erkannten Markierungen)

B Spaltennummer mit der maximalen Anzahl an nicht-schwarzen Pixeln

Seite 26


Wurde nur eine Markierung erkannt, wird die Spaltennummer aus Punkt B er-kannt. Wenn mehr als eine Markierung erkannt wurde, geht der Algorithmusdavon aus, dass der Benutzer eine doppelte (ungültige) Markierung vorgenom-men hat. Wenn in einer Zeile kein einziger nicht-schwarzer Pixel erkannt wur-de, wird keine Antwort ermittelt.

Der Grund, dass bei einer erkannten Markierung keine 4% der Pixel gefülltsein müssen liegt darin, dass die Markierungsmuster der Befragten sehr vari-antenreich ausfällt, obwohl der Fragebogen vorgibt mit Kreuzen zu markieren.So wir der Grenzwert bei Markierungen mit kleinen Punkten nicht erreicht.

5.3.5 Iteration 5: Optimierung der grafischen Benutzerschnittstelle undNutzererfahrung

In der letzten Iteration sollte die grafische Benutzerschnittstelle umstrukturiertund angepasst werden. Diese sollte sich nur aus den notwendigen Komponen-ten zusammen setzen und keine zusätzlichen anzeigen enthalten, die den Be-nutzer womöglich verwirren. Bei der Analyse der Benutzerschnittstelle stelltensich die Scrollleiste, die die Miniaturansichten der Seiten enthält und die Sei-tenansicht für die einzelne Seite zum Konstruieren der Raster als notwenigeKomponenten zur Navigation und Bearbeitung der Fragebogenvorlage heraus.Die Liste in der Implementierung des Prototypen (Abbildung 3) zeigt den Da-teinamen der geöffneten Fragebogenvorlage an. Bei dem Prototypen ist sowohlfür das Speichern der Raster, als auch für das Laden der Raster ein Buttonvorhanden. Im Allgemeinen ist das Panel für die Buttons und Textfelder zubreit, was den sichtbaren Bereich, der aktuell ausgewählten Seite schrumpfenlässt, wodurch beim Anlegen der Raster oftmals gescrollt werden muss. Da-her sollte die überarbeitete Version nur auf die notwendigsten Komponentenreduziert werden, was zum Design in Abbildung 4 führte. Zusätzlich wird statt“Skip Pages“ bei geöffneter Vorlage die aktuell angezeigte Seitenzahl angezeigt(Abbildung 4). Im Zuge dieser Änderung wurde der Layoutmanager vom Grou-playout durch andere Layoutmanagerkombinationen ersetzt, sodass nun auchder Quelltext für die grafische Benutzerschnittstelle übersichtlicher ist.

Bei der Darstellung der grafischen Benutzerschnittstelle des Auswertungsfens-ters beim Prototypen gibt es bei der Darstellung unter Mac OS kleine Darstel-lungsfehler, die behoben werden sollten, da das Programm in Java geschrie-ben ist und auf zahlreichen Plattformen vernünftig dargestellt und benutztwerden soll. Das Abspeichern der ausgewerteten Ergebnisse ist in der über-arbeiteten Version nach wie vor möglich, jedoch ist der Dateiname der CSV-

Seite 27


Datei durch den Namen der Fragebogenvorlage vorgeschrieben. Die Textfelder,die die erkannten Spaltennummern enthalten sind durch das neue Werkzeugauch überflüssig und nehmen kein Platz von der Seitenansicht weg.

Die abschließenden Entwicklungsarbeiten bestanden darin, die Benutzung desProgramms möglichst verständlich zu gestalten. Dazu gehörten aussagekräf-tige Nachrichten in Form von einem ladenden Cursorsymbol oder auch Mel-dungen, sodass der Anwender stets weiß, was das Programm durchführt oderbereites durchführte.

Dies betrifft meistens sinnlose Aktionen, wie zum Beispiel das Speichern vonRastern oder Dateien zum Analysieren auszuwählen, ohne eine Fragebogen-vorlage geöffnet zu haben. Außerdem wird beim Speichern der Raster genausowie beim Speichern der Auswertungsergebnisse der Speicherpfad mit angege-ben, sodass diese Dateien abschließend leicht zu finden sind.

Darüber hinaus werden die gezeichneten Raster nicht selbstständig in eine Da-tei gespeichert. Der Anwender muss den entsprechenden Button dafür drücken.Sollte der Benutzer das Speichern vor dem Schließen der Vorlage oder des Pro-gramms versehentlich vergessen, führt es zu einer Speicherabfrage, um dievorhandenen Raster zu speichern.

Wird eine Fragebogenvorlage geladen zu der keine gespeicherten Raster gefun-den wurden, wird der Benutzer ebenfalls darüber informiert.

Verbesserung der NutzererfahrungDarüber hinaus wurden in der 5. Iteration auch viele Elemente eingebaut,die die Nutzererfahrung verbesserten. Die Analyse des Prototypen zeigte, dassbeim Schließen einer Vorlage nach der Erstellung eines Rasters keinerlei War-nung erscheint, dass die Raster nicht gespeichert werden. Diese Funktiona-lität ist heutzutage in nahezu jeder Software enthalten, wodurch sie vielenBenutzern vertraut ist und eventuell auch erwartet. Außerdem kommen in-formierende Meldungen, wenn der Benutzer versucht die Raster zu speichernoder ausgefüllte Fragebögen auszuwerten ohne, dass eine Vorlage geöffnet ist.Hinzu macht das Auswerten von Fragebögen nur Sinn, wenn mindestens einRaster definiert wurde, was nach dieser Iteration auch überprüft wird. Umdie nachträgliche Überprüfung neben den transparenten Farbhintergründennoch schneller zu gestalten, werden auf den auszuwertenden Fragebögen aus-schließlich Seiten angezeigt auf denen mindestens ein Raster erstellt wurde.Dadurch muss der Prüfende nicht mehr durch rasterlose Seiten blättern.

Seite 28


Abbildung 3: Grafische Benutzerschnittstelle des Prototypen

Abbildung 4: Grafische Benutzerschnittstelle nach Iteration 5

Seite 29

Vergleich Prototyp <-> Re-Implementierung

6 Vergleich Prototyp <-> Re-Implementierung

Dieses Kapitel vergleicht den Prototyp mit der Re-Implementierung, wobei be-sonderer Wert auf die verschiedenen Funktionsweisen der Rastererstellung,der Auswertungsalgorithmen und der Sichtprüfung gelegt wird. Ein weitererAbschnitt untersucht Unterschiede bei der Performance.

6.1 Rasterimplementierung

Wie im Abschnitt 2.1 beschrieben, bietet der Prototyp zwei Möglichkeiten derRasterbildung, wohingegen die Re-Implementierung nur eine bietet.

Beide Möglichkeiten des Prototypen setzen voraus, dass die Spaltenbreiten derAntwortalternativen gleich groß sind. Ebenso muss die Zeilenhöhe der ein-zelnen Fragen pro Seite gleich viel Platz in Anspruch nehmen. In der Praxiszeigte sich, dass bei beiden Methoden das zu erstellende Raster sehr häufignicht dem Fragebogenraster angepasst werden konnte, insbesondere bei einergrößeren Anzahl von Fragen (Zeilen). Bei der zweiten Methode kann das initi-ierende Rechteck oft auch dann nicht genau genug gezogen werden, wenn dieZeilen und Spalten auf einer Seite gleich hoch bzw. breit sind.

Bei der Re-Implementierung gibt es die oben genannte Problematik nicht. Dieeinzelnen Zeilen und Spalten können optimal und individuell nachjustiert wer-den.

Einen exemplarischen Vergleich zur Rasterbildung zeigen die Abbildungen 5und 6. Daraus wird deutlich, dass der Prototyp durch die dritte Frage, diesich über zwei Textzeilen erstreckt, aufgrund der festen Zeilenhöhe des erstell-ten Rasters gravierende Zeilenverschiebungen aufweist. In der Folge kommt esin diesem konkreten Fall bei der Auswertung zu fehlerhaften Markierungser-kennungen (Abbildung 7), obwohl die Kreuze relativ sauber gesetzt wurden.Bei der Re-Implementierung hingegen wird durch die Anpassungsfähigkeit desRasters jedes einzelne Kreuz korrekt erkannt (Abbildung 8).

Bei der Zeitmessung (Tabelle 2) wird deutlich, dass die Erstellung des Rastersbei der Re-Implementierung zeitintensiver ist als beim Prototypen. Die zusätz-liche, exakte Anpassung der Zeilenhöhen und Spaltenbreiten an die Fragebo-gentabelle kostet etwas mehr Zeit.

Seite 31


Abbildung 5: Gleichmäßiges Grid Abbildung 6: Nachjustierbares Grid

Tester Vorbereitung (Proto) Überprüfung (Proto) Vorbereitung Überprüfung1 0:50 14:13 1:58 1:582 1:36 12:08 1:22 2:133 2:15 13:12 2:08 2:164 1:38 15:03 2:02 1:505 1:13 14:12 1:22 1:56

Tabelle 2: Zeitmessung (in Minuten) beider Versionen von QValuate bei derVorbereitung der Fragebogenvorlage und der nachträglichenÜberprüfung der Auswertung von 10 ausgefüllten Fragebögen mit 3Tabellen mit insgesamt 59 Fragen.

6.2 Auswertungsalgorithmen

Der Algorithmus des Prototypen arbeitet mit einer Mindestanzahl an Pixeln,die relativ zur Zellengröße markiert sein müssen, damit eine Markierung er-kannt wird. Bei der Analyse der ausgefüllten Fragebögen wurde deutlich, dassdie Markierungsarten sich sehr vielseitig gestalteten [Klu12, S. 9].

Durch die Vielzahl von verschiedenen Markierungsarten wurde ein fest ein-programmierter Grenzwert kritisch gesehen, da die extremen Markierungsar-ten aus sehr geringen Anzahl an Pixeln bestanden. Daher wurde in der Re-Implementierung ein Algorithmus entwickelt, der einerseits das Feld der meis-ten markierten Pixel ausfindig macht, sowie die Anzahl der Zellen, die einerelative Pixelzahl von mindestens 4% aufweisen. Auf diese Weise werden eben-falls kleine punktartige Markierungen erkannt, da die Spalte mit der maxima-len Anzahl an Pixeln als Ergebnis gespeichert wird, wenn maximal eine Zellemehr als 4% Pixel enthält. Grundsätzlich gilt das Problem, dass bei zu nied-rigem Grenzwert hingegen, benachbarte überragende Pixel als Markierungenerkannt werden, da diese schon den relativen Grenzwert überschreiten. Bei

Seite 32


Abbildung 7: Auswertung desgleichmäßigen Grids

Abbildung 8: Auswertung desnachjustierbaren Grids

einem zu hohen Grenzwert hingegen, wird der Grenzwert von gewollten Mar-kierungen nicht erreicht.

Die Auswertung beim Prototypen unterscheidet zwischen verschiedenen Artender Erkennung. “Eindeutig bestimmbare“ Erkennungen (grün gekennzeichnet)sollen so sicher erkannt worden sein, dass sie vom Prüfer bei der Sichtprü-fung ausgelassen werden können. “Nicht eindeutig bestimmbare“ Erkennun-gen (rot gekennzeichnet) müssen vom Prüfer korrigiert werden, da der Algorith-mus sich dort auf keine Antwort festsetzt. Die Bewertung des Algorithmus beidieser Vorgehensweise unterscheidet dabei zwischen Erkennungsrate, Fehler-rate und Nachbearbeitungsrate. Die Erkennungsrate gibt an, wie viel Prozentvon den Fragen die Software richtig erkannt hat. Die Fehlerrate beschreibt diefalsch erkannten Antworten. Die Nachbearbeitungsrate beschreibt, wie vieleFragen in der Sichtprüfung noch betrachtet werden müssen. Die beste Erken-nungsrate des Prototypen lag bei 96,4%. [Klu12, S. 24 ff.]

Da es sich bei den Fragen um sehr sensible Daten handelt wurde bei der Re-Implementierung davon abgesehen Ergebnisse als “eindeutig bestimmbar“ ein-zustufen, sodass sie in der Sichtprüfung ausgelassen werden könnten. Die Re-Implementierung sieht vor, dass sich jede der erkannten Spalten einer Sicht-prüfung unterziehen muss, wodurch auch nur der Wert einer Fehlerrate ent-steht, der mit der Erkennungsrate verglichen werden kann. Die Auswertungs-

Seite 33


ergebnisse wurden automatisiert mit einem manuell erstellten und doppeltabgeglichenem Datensatz verglichen. Bei einem Durchlauf einer Fragebogen-reihe mit 59 Fragen aufgeteilt auf drei Raster, ergab der Algorithmus der Re-Implementierung bei 49 ausgefüllten Fragebögen (2891 Fragen) eine Fehlerratevon 1,1%, was einer Erkennungsrate von 98,9% entspricht.

6.3 Sichtprüfung

Nach der automatischen Auswertung der Fragebögen durch das Programmmüssen die Ergebnisse einer Sichtprüfung unterzogen werden. Die erkann-ten Markierungen müssen dabei noch einmal überprüft werden, da es bei dervariantenreichen Eingabemöglichkeit dennoch zu Fehlerkennungen kommenkann. Dabei muss der Anwender in der vorherigen Version die angezeigte Num-mer im Textfeld mit der Spaltennummer vergleichen (Abbildung 7). Die grüneFarbe stuft die Erkennung dabei als “eindeutig bestimmbar“ ein [Klu12]. DasProblem bei dieser Art der Überprüfung besteht darin, die Nummer des Text-feldes selber auf die Spaltennummer abzubilden. Vom Benutzer müssen zweiverschiedene Punkte visuell erfasst und verglichen werden.

Optimiert wurde dieser Abgleich durch eine farblich-transparente Hinterle-gung der Zelle, auf der eine Markierung erkannt wurde (Abbildung 8). Dabeikann der Anwender die Markierung selber stets deutlich erkennen und we-sentlich schneller überprüfen, ob das richtige Feld erkannt wurde. Darüberhinaus können Fehlerkennungen komfortabel durch das Klicken auf die kor-rekte Zelle korrigiert werden. Auf diese Weise muss die falsche Spaltennummernicht aus dem Textfeld gelöscht und die korrekte Nummer eingefügt werden,was ebenfalls Zeit spart. Außerdem werden nur die Seiten der ausgefülltenPDF-Dateien angezeigt, die auch Raster enthalten, wodurch alle irrelevantenInformationen für den Prüfenden ausgeblendet werden. Diese Optimierungenlassen sich ebenfalls deutlich in der Anwendung bei der Zeitmessung quantifi-zieren, da die sich die nachträgliche Überprüfung bei der neuen Implementie-rung in einem Bruchteil der Zeit durchführen lässt.

6.4 Performance

Bei der vorigen Version wurde ebenfalls der langsame Wechsel der Seiten beider Fragebogenvorlage sowie beim Wechsel der evaluierten Dateien bemän-gelt. Dies war für die Benutzererfahrung äußerst störend. Die Auswertung derDateien wurde in der vorherigen Version erst beim Wechseln der Seite voll-zogen. Diese Auswertung ist auch schon bei einer geringen Anzahl an Ras-

Seite 34


tern relativ zeitaufwändig, sodass es zu einer kurzen Ladezeit kommt. Die Re-Implementierung benötigt beim Laden der ausgefüllten PDF-Dateien einen er-höhten Zeitaufwand, wechselt dann aber flüssig die Seiten und Dateien. Beider Auswertung von 2891 werden 9 Sekunden auf einer aktuellen Computer-architektur benötigt.

6.5 Softwarearchitektur

Beim Vergleich der verschiedenen Architekturen (Tabellen 1 und 3) wird durchdie Metriken deutlich, dass die Anweisungen pro Methode in der neuen Archi-tektur durchschnittlich bei 14,7 statt 20 liegen. Kurze Methoden werden fürdie Lesbarkeit und für das Verständnis des Quelltextes bevorzugt. Außerdemsind die Anzahl der Methoden pro Klassen ebenfalls von 10 auf 8,5 gesun-ken [Mar08, S. 176]. Dennoch ist der Umfang des Programms sehr ähnlichgeblieben. Beide Architekturen weisen einen Quelltextumfang von etwas über2000 Anweisungen auf, wobei die Anzahl der Methoden im Gegenzug von 112auf 161 gestiegen ist. Durch die geringeren Ausmaße der Methoden sind sieübersichtlicher und für den Entwickler leichter zu waten.

Seite 35

Architektur der Re-Implementierung

7 Architektur der Re-Implementierung

Im Folgenden wird die Zuständigkeit der wichtigsten neu entwickelten Pro-grammelemente nach der Umsetzung der fünf Iterationen beschrieben. DieUnterstruktur dieses Kapitels orientiert sich an die Paketeinteilung nach demWAM-Ansatz. Die Pakete enthalten jeweils die strukturrelevanten Klassen.

7.1 Werkzeuge

7.1.1 QValuateWerkzeug

Mit dem QValuateWerkzeug wird die PDF-Vorlage geladen und bearbeitet. DasWerkzeug arbeitet hauptsächlich mit dem Service PDFService und dem Ma-terial Pdffile. Diese Klasse referenziert ein Exemplar der dazugehörigen UI-Klasse, sodass die grafische Benutzerschnittstelle von der Funktionalität ge-trennt ist. In ihr werden die Actionlistener der einzelnen Buttons, Menüein-träge und Mausereignisse angemeldet. Dabei besteht ein wesentlicher Teil ausder Erzeugung und Anpassung der veränderbaren Raster (ResizableGrid).

7.1.2 EvaluateWerkzeug

Nach Vorbereitung der Vorlage mit den Rastern, wird zum Auswerten ein Ex-emplar der Klasse EvaluateWerkzeug erzeugt. Dabei werden dem Konstruktordie PDF-Vorlage und die ausgefüllten PDF-Dateien übergeben. Darin sind allenötigen Informationen zur Auswertung der Dateien enthalten um die Auswer-tung zu beginnen. Nachdem die automatische Auswertung die einzelnen Rasterausgewertet hat, werden auf den ausgefüllten Fragebögen die erkannten Mar-kierungen dem Auswertungsalgorithmus entsprechend (Abschnitt 5.3.4) farb-lich transparent hinterlegt. Bei einer grünen Hinterlegung hat der Algorithmussich für eine Spalte entschieden, wohingegen er bei einer zeilenweisen rotenHinterlegung keine eindeutige Markierung ausfindig machen konnte. Wird garkeine Markierung erkannt, werden keine Zellen der jeweiligen Frage farblichhinterlegt.

Auch diese Klasse referenziert wie die Klasse QValuateWerkzeug ein Exemplareiner UI-Klasse, die für die Komponenten der grafischen Benutzerschnittstellezuständig ist. Diese UI-Klasse enthält sondierende Methoden für die Kompo-nenten, sodass die Werkzeugklasse die Funktionalität der Elemente implemen-tieren kann. Auch die Klickfunktionen zum Korrigieren der erkannten Einga-ben sind in der Klasse implementiert.

Seite 37


Abbildung 9: Paketstruktur von QValuate mit WAM

7.2 Services

7.2.1 PDFService

Dieser Service referenziert die anfangs geladene Fragebogenvorlage und spei-chert die dazugehörigen Miniaturbilder, damit diese nicht erneut geladen wer-den müssen. Außerdem speichert der Service die aktuell angezeigte Seiten-nummer, und wird im Rahmen des Beobachter-Entwurfmusters “beobacht-bar“. Dabei informiert der Service alle angemeldeten Beobachter, wenn es zueinem Seitenwechsel kommt. Darüber hinaus kann vom Service erfragt wer-den, ob die rasterspeichernde Datei gerade den aktuellen Zustand speichert.Dies ist für die Speicherabfrage vor dem Schließen der Vorlage oder Beendendes Programms erforderlich.

7.2.2 GridWritingService

Dieser Service ist für das Laden und Speichern der Datei, in der die Exempla-re der Klasse ResizableGrid gespeichert werden, zuständig. Beim Lesen derDatei wird ein Exemplar der Klasse Object geladen, das anschließend wiederin eine Liste von Listen mit ResizableGrid Exemplaren umgewandelt wird.Die Indexposition der Listen bildet die Seitenzahl ab, auf der sich die Rasterbefinden.

7.3 Materialien

7.3.1 ResizableGrid

Das ResizableGrid ist eine wesentliche Neuentwicklung, die die erweitertenAnforderungen an die Raster bereitstellt. Darunter fällt das komfortable Er-

Seite 38


Abbildung 10: Klassenstruktur von der Re-Implementierung mit WAM

stellen der Raster, sowie das anschließende Anpassen der einzelnen Zeilen-höhen und Spaltenbreiten. Damit die Informationen aus dieser Klasse in ei-ne Datei gespeichert werden können, ist es erforderlich, dass sie die Klassejava.lang.Serializable aus dem Javaframework erweitert.

Zu Beginn der Erstellung werden in den entsprechenden Textfeldern die An-zahl der Zeilen und Spalten festgelegt. Zur Rastererstellung wird mit der Mauszum linken oberen Punkt des zu markierenden Rasters navigiert. Die linkeMaustaste wird hier gedrückt und gehalten und das Raster durch Ziehen derMaus nach unten rechts aufgezogen. Beim Loslassen der Maustaste wird derrechte untere Punkt des Rasters fixiert. Die Zeilen und Spalten werden zu-nächst gleichmäßig verteilt angezeigt. Jedes Raster lässt sich zu jeder Zeitdurch Rechtsklick auf das entsprechende Raster entfernen.

Anschließend können durch das Ziehen an den kleinen Rechtecken am linkenRand der Zeilen bzw. oben an den Spaltenbegrenzungen die Zeilenhöhen undSpaltenbreiten bestmöglich an das Raster des Fragebogens angepasst werden.Das Element basierte auf den unter Abschnitt 5.3.2 beschriebenen Prototypen,bei dem die Handhabung der Nachjustierung von Zeilen und Spalten im Vor-dergrund stand.

Diese Klasse gehört zum Paket der Materialien, da das QValuateWerkzeug Ex-emplare von ihr erstellt und anpasst. Ein Exemplar der Klasse ResizabeGrid

speichert zwei Punkte (oben links und unten rechts), die die Gesamtgröße desRasters definieren. Gespeichert werden außerdem die Anzahl der Zeilen undSpalten, die zur Verfügung gestellt werden sollen, sowie zwei Listen, die Exem-plare der Klasse Rectangle speichern. Diese Exemplare dienen der Definitionder einzelnen Zeilenhöhen und Spaltenbreiten. Darüber hinaus sind sie die

Seite 39


Anklickpunkte für die Größenanpassungen.

Zu jeder Zeilen- und Spaltenbegrenzung gehört ein Rectangle-Exemplar, dasangepasst werden kann. Durch die Koordinaten der Exemplare lassen sich dieDimensionen jeder einzelnen Zelle in einem Raster bestimmen (Abb. 6).

7.3.2 Pdffile

Je ein Exemplar der Klasse Pdffile wird für die Vorlage sowie für die aus-gefüllten, zu analysierenden Fragebögen erstellt. Das Exemplar der Vorlagebeinhaltet im Wesentlichen eine Liste von Listen, die Exemplare der Klas-se ResizableGrid enthalten. Jede Liste von ResizableGrid-Exemplaren be-schreibt dabei eine Seite, wobei auch mehrere Raster pro Seite definiert wer-den können. Darüber hinaus werden analog dazu geschachtelte Listen gespei-chert, die BufferedImage-Exemplare für die Bildausschnitte, die durch dieRaster definiert werden, enthalten. Schließlich speichert jede PDF-Datei nachder Evaluierung die Ergebnisse der einzelnen Zeilen. Dies wird ebenfalls durchgeschachtelte Listen von RowResult-Exemplaren realisiert. Nach dem auto-matisierten Auswertungsteil, wenn also die Ergebnisse feststehen, werden dieBildausschnitte gelöscht um Speicherplatz zu sparen.

7.4 Fachwerte

7.4.1 RowResult

Ein Exemplar der Klasse RowResult repräsentiert den Zustand eines Zeilener-gebnisses. Dabei speichert es entweder die Spaltennummer (beginnend bei 0)oder eine negative Zahl, wenn keine Eingabe (-1) bzw. doppelte Eingaben (-2)erkannt werden.

Der Zustand kann komfortabel als Text ausgegeben werden, um das Ergebnisabschließend in eine CSV-Datei zu schreiben. Das Ergebnis für die Spalten-nummer wird dabei um eins erhöht, damit die Darstellung der Spaltennummerin der CSV-Datei bei eins beginnt. Eine doppelte Eingabe (Wert = -2) wird in derspäteren CSV-Datei mit “D“, eine leere Zeile (Wert = -1) mit “NA“ ausgewiesen.Zusätzlich kann die Farbe abgefragt werden, die den Zustand repräsentiert.Außerdem vergleicht die überschriebene Methode equals auf Gleichheit desZustandes.

Seite 40


Gesamt startup werkzeuge services materialien fachwertePakete 5 - - - - -

Klassen 18 1 6 8 3 1Anweisungen 2249 13 1298 387 475 76

Methodenanzahl 154 1 64 31 49 9Anweisungen pro Methode 14,70 13 20,28 12,48 9,69 8,44

Methoden pro Klasse 8,5 1 10,67 3,88 16,33 9Afferent Coupling (Ca) - 0 1 3 4 2

Tabelle 3: Metriken der Re-Implementierung (erstellt mit dem Eclipse-PluginMetrics)

Seite 41

Zusammenfassung und Ausblick

8 Zusammenfassung und Ausblick

Der Prototyp, der Grundlage dieser Arbeit war, erwies sich als gute Basisfür eine Weiterentwicklung. Insbesondere konnte auf die grafische Benutzer-schnittstelle zurückgegriffen werden, sodass der Schwerpunkt auf Fragebo-genanpassung und Auswertungsgeschwindigkeit gelegt werden konnte. Au-ßerdem konnte der Ablauf der Programmnutzung übernommen werden. AlsProgrammbezeichnung der Re-Implementierung wäre in Anlehnung an denPrototyp nunmehr zur Abgrenzung QValuate 2 als neue Bezeichnung sinnvoll.

Im Folgenden werden Ausbaumöglichkeiten dargestellt, die für den produkti-ven Einsatz der Software hilfreich wären und Spielraum für weiterführendeEntwicklungsarbeiten an dem Programm lassen.

Auswertung zwischenspeichern

Bei der Überprüfung der Fragebogenauswertungen gibt es momentan keineFunktion, um Zwischenzustände zu laden oder zu speichern. Daher muss derAnwender die Überprüfung der erkannten Ergebnisse in einem Schritt durch-führen und darf das Programm nicht beenden, da keine Zwischenspeicherungder Ergebnisse erstellt werden kann. Eine interessante Erweiterung bestündedarin eine Zwischenspeicherung erstellen zu können, die eine Markierung desFortschritts beinhaltet. Diesen Zustand könnte der Anwender zu einem späte-ren Zeitpunkt öffnen und die Sichtprüfung an der markierten Stelle fortführen.Auf diese Weise könnten selbst große Umfragen etappenweise ausgewertet undüberprüft werden.

Heapspace

Der hohe benötigte Speicher, der bei der Ausführung von QValuate 2 benö-tigt wird, ist deutlich abhängig von der Anzahl der geöffneten PDF-Dateien.Der Ursache und Behebung des hohen Speichervolumens konnte leider nichtmehr nachgegangen werden, da der zeitliche Rahmen der Arbeit auf drei Mo-nate beschränkt war. Das Öffnen aller Dateien zur Auswertung hat einerseitsden Vorteil, dass die Dateien allesamt im Arbeitsspeicher vorliegen und dasWechseln der einzelnen Dateien sehr schnell passiert. Eine Option die Aus-wertung weiterhin zu optimieren wäre der Ausbau zu einer parallelen und spei-chereffizienteren Methode. Dabei würden die heutigen Mehrkernarchitekturendurch die Hyperthreading Technologie eine parallele Implementierung wesent-lich schneller ausführen können.

Seite 43

Zusammenfassung und Ausblick

Momentan benötigt eine Auswertung von 30 Fragebögen à 17 Seiten 1,81GBSpeicher. Die Profilerstellung des Speichers mithilfe von VisualVM [Vis12] weistnach, dass genau zu dem Zeitpunkt, wo das Auswerten der ausgewählten Da-teien gestartet wird, die Speicherauslastung immens ansteigt.

Der Prototyp hingegen verbraucht bei dieser Menge an Fragebögen lediglich250MB Speicher. Grundsätzlich muss häufig abgewogen werden, ob es an-fangs zu einer längeren Ladezeit kommen soll oder beim Dateiwechsel zu einerkurzen Ladezeit. Eine andere Möglichkeit bestünde darin verschiedene PDFFrameworks zu vergleichen und herauszufinden, ob es vielleicht an dem ver-wendeten JPedal [IDR12] liegt.

Algorithmus KreuzerkennungEin weiterer Punkt besteht darin, die Software bezüglich des Algorithmus zurErkennung der Markierung auszubauen. Eventuell könnten Algorithmen ent-wickelt werden, die das Korrigieren einer Markierung erkennen können, odersich der Markierungsart, entweder durch menschliche Hilfe oder selbststän-dig, anpassen und auf diese Weise lernfähig sein würden und sich den Markie-rungen anpassen. Dabei könnten verschiedene Implementierungen nach einerbreiten Anwendung auf ausgefüllte Fragebögen statistisch miteinander vergli-chen und so optimiert werden. Die Qualität des Algorithmus kann durch dieAnzahl der Zeilen bewertet werden, die nachträglichen korrigiert werden muss-ten. Dabei müsste auch statistisch analysiert werden, aus wie vielen Pixeln ei-ne typische Markierung besteht, um geeignete Grenzwerte für die Erkennungeiner markierten Zelle oder eine nachträglich verworfene Markierung zu fin-den.

Seite 44

Literatur

Literatur

[Bö09] BÖSCHEN, Ingmar: Der “e-paper-pencil“ Fragebogen, Äquivalenzüber-prüfung einer Papier- Bleistift- und e-paper-pencil-Testung. 2009

[Col12] COLLABNET: Subclipse. http://subclipse.tigris.org/, 2012. –[Online; zugegriffen 16-Juli-2012]

[Cor12] CORPORATION, Oracle: Designing a Swing GUI in NetBe-ans IDE. http://netbeans.org/kb/docs/java/quickstart-gui.html, 2012. – [Online; zugegriffen 11-July-2012]

[HL10] HORST LICHTER, Jochen L.: Software Engineering. 2. Auflage. dpunktVerlag, 2010

[Hum11] HUMMEL, Oliver: Aufwandsschätzungen in der Software- und Syste-mentwicklung kompakt. Spektrum Akademischer Verlag, 2011

[IDR12] IDRSOLUTIONS: JPedal. http://www.jpedal.org/, 2012. – [Online;zugegriffen 17-August-2012]

[Klu12] KLUDT, Dalja: Entwicklung einer Software zur teilautomatisierten Aus-wertung handschriftlich ausgefüllter Fragebögen in der psychologi-schen Diagnostik. 2012

[LLC12] LLC, ObjectAid: ObjectAid. http://www.objectaid.com/, 2012. –[Online; zugegriffen 30-August-2012]

[Mar08] MARTIN, Robert C.: Clean Code, A Handbook of Agile Software Craft-manship. 1. Auflage. Prentice Hall International, 2008

[Men12] MENTOR, Object: JUnit.org. http://www.junit.org/, 2012. – [On-line; zugegriffen 18-August-2012]

[MF99] MARTIN FOWLER, John Brant William Opdyke don R. Kent Beck B.Kent Beck: Refactoring: Improving the Design of Existing Code.Addison-Wesley Longman, 1999

[SOF12] STATE OF FLOW, Lance W.: Metrics. http://eclipse-metrics.

sourceforge.net/, 2012. – [Online; zugegriffen 18-August-2012]

[Sta09] STARKE, Gernot: Effektive Software Architekturen. 4. Auflage. HanserVerlag, 2009

[Vis12] VISUALVM: VisualVM. http://visualvm.java.net/, 2012. – [On-line; zugegriffen 21-September-2012]

[Zü98] ZÜLLIGHOVEN, Heinz: Das objektorientierte Konstruktionshandbuch.1. Auflage. dpunkt Verlag, 1998

Seite 45

http://subclipse.tigris.org/

http://netbeans.org/kb/docs/java/quickstart-gui.html

http://netbeans.org/kb/docs/java/quickstart-gui.html

http://www.jpedal.org/

http://www.objectaid.com/

http://www.junit.org/

http://eclipse-metrics.sourceforge.net/

http://eclipse-metrics.sourceforge.net/

http://visualvm.java.net/

Abbildungsverzeichnis

Abbildungsverzeichnis

1 Sichtprüfung nach der Auswertung . . . . . . . . . . . . . . . . . . 62 Paketstruktur von QValuate (Prototyp) . . . . . . . . . . . . . . . . 173 Grafische Benutzerschnittstelle des Prototypen . . . . . . . . . . . 294 Grafische Benutzerschnittstelle nach Iteration 5 . . . . . . . . . . 295 Gleichmäßiges Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Nachjustierbares Grid . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Auswertung des gleichmäßigen Grids . . . . . . . . . . . . . . . . . 338 Auswertung des nachjustierbaren Grids . . . . . . . . . . . . . . . 339 Paketstruktur von QValuate mit WAM . . . . . . . . . . . . . . . . 3810 Klassenstruktur Re-Implementierung mit WAM . . . . . . . . . . . 39

Seite 47

Erklärung

Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasstund keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe,dass alle Stellen der Arbeit, die wörtlich oder sinngemäß aus anderen Quellenübernommen wurden, als solche kenntlich gemacht sind und dass die Arbeitin gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegt wurde.Außerdem bin ich damit einverstanden, dass diese Arbeit in der Bibliothekausgestellt wird.

Hamburg, den 25. September 2012 Marlo Häring

Seite 49

Date post:	17-Aug-2019
Category:	Documents
Upload:	leque
View:	215 times
Download:	0 times

Bachelorarbeit im Fachbereich Informatik · gramms liegt der Fragebogen blanko, also unausgefüllt...

Documents