Bachelorarbeit
Entwicklung einer Applikation zur Erfassung und Ausgabe von Titrationsmessdaten
als webbasierter Workflow
Fachbereich Elektrotechnik und Informatik Fachrichtung
Angewandte Informatik
Name: Alexander Kuhn Matrikelnummer: 578748 Erstellt bei: Miele & Cie. KG in Gütersloh
Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster Zweitprüfer: Dipl.-Ing. Andreas Tono, Miele & Cie. KG
II
Danksagung
Mein erster Dank gilt Herrn Prof. Dr. rer. nat. Nikolaus Wulff für seine Unterstützung
und die Betreuung meiner Arbeit.
Des Weiteren bedanke ich mich bei meinem Mitarbeiter und Miele internen Betreuer
Herrn Dipl.-Ing. Andreas Tono für seine hilfreichen konstruktiven Kommentare und
die angenehme Zusammenarbeit.
Mein besonderer Dank gilt meiner Familie und meiner Freundin, auf die ich mich zu
jeder Zeit verlassen kann und die hierdurch wesentlich zum Erfolg dieser Arbeit
beigetragen haben.
Weiterhin bedanke ich mich bei allen anderen Personen die mich bei der Anfertigung
dieser Arbeit in unterschiedlicher Weise unterstützt haben.
III
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig angefertigt und
dabei nur die angegebenen oder bei Zitaten kenntlich gemachten Quellen und Hilfs-
mittel verwendet habe.
Ennigerloh, den ________________ _____________________________
Alexander Kuhn
IV
Sperrvermerk
Der Inhalt dieser Bachelorarbeit unterliegt der Geheimhaltung. Ohne die
ausdrückliche Zustimmung der Firma Miele & Cie. KG ist die Veröffentlichung,
Vervielfältigung oder Weitergabe an Dritte nicht gestattet.
V
Abstract
Diese Bachelorarbeit wurde bei der Firma Miele & Cie. KG in Gütersloh im Zeitraum
von Juli bis September 2011 erstellt und stellt den Abschluss meines
Bachelorstudienganges Angewandte Informatik an der Fachhochschule Münster dar.
In der Firma Miele wird ein neues System (ProLab) zur Verwaltung von Prüfungen
eingeführt. Diese Bachelorarbeit ist ein Teilprojekt des Großprojekts ProLab.
Inhalt dieser Bachelorarbeit ist die Konzeption und die Implementierung einer Web-
Applikation, die als Modul in das Großprojekt eingebunden wird. Die Applikation soll
Messdaten der Titrationsvorgänge erfassen und als webbasierten Workflow dem
Anwender zur Verfügung stellen.
Zunächst einmal werden die Grundlagen und Techniken, die für die Realisierung des
Projekts benötigt werden, genannt.
Im Anschluss wird der derzeitige Prüfprozess des Labors für Verfahrensprüfung
vorgestellt und analysiert.
Darauf aufbauend wird das von mir erstellte Lösungskonzept, welches den
derzeitigen Prozess ersetzten soll, dargestellt.
Danach wird das von mir zu implementierende Modul Titration vorgestellt. Es werden
Masken aus der Web-Applikation gezeigt, die die Implementierung verdeutlichen
sollen.
Zum Schluss gibt ein Fazit Aufschluss darüber, in wie weit sich mein entwickeltes
Modul auf das Großprojekt und die Prüflabore auswirkt.
VI
Inhaltsverzeichnis
1 Einleitung ............................................................................................................. 1
1.1 Unternehmensprofil ....................................................................................... 1
1.2 Abteilung KEW und LD .................................................................................. 2
1.3 Hintergrund und Motivation ........................................................................... 2
1.4 Zielsetzung .................................................................................................... 3
1.5 Gliederung der Arbeit .................................................................................... 3
2 Grundlagen .......................................................................................................... 4
2.1 Miele Prüfungsverwaltungssystem ................................................................ 4
2.1.1 LabDB ..................................................................................................... 4
2.1.2 ProLab .................................................................................................... 8
2.2 Sprachen ..................................................................................................... 11
2.2.1 Java ...................................................................................................... 11
2.2.2 HTML .................................................................................................... 11
2.2.3 CSS ...................................................................................................... 12
2.2.4 JSP ....................................................................................................... 12
2.2.5 SQL ....................................................................................................... 14
2.3 Server und Applikationen ............................................................................ 17
2.3.1 Apache Tomcat ..................................................................................... 17
2.3.2 Informix Datenbank ............................................................................... 21
2.3.3 Netbeans............................................................................................... 22
3 Prozessanalyse ................................................................................................. 23
3.1 Derzeitiger Prüfprozess im Labor VP .......................................................... 23
3.1.1 Datenverarbeitung ................................................................................ 23
3.1.2 Prozessablauf ....................................................................................... 24
3.1.3 Bewertung des aktuellen Prozesses ..................................................... 27
4 Konzeption ........................................................................................................ 28
VII
4.1 Analyse der Technik .................................................................................... 28
4.1.1 Dateneingabe ........................................................................................ 31
4.1.2 Datenausgabe ....................................................................................... 31
4.2 Anforderungen ............................................................................................. 32
4.2.1 Konzeptionelle Anforderungen .............................................................. 32
4.2.2 Technische Anforderungen ................................................................... 34
4.3 Entwurf ........................................................................................................ 35
4.3.1 PC-System & die Schnittstelle Com-Server .......................................... 35
4.3.2 Modul Titration ...................................................................................... 38
4.3.3 Applikation zur Netzwerkkommunikation .............................................. 44
5 Implementierung ................................................................................................ 48
5.1 Organisatorisches ........................................................................................ 48
5.1.1 Vorgehensmodell .................................................................................. 48
5.1.2 Eingesetzte Technologie und Werkzeuge ............................................. 48
5.2 Allgemeine in ProLab verwendete Techniken ............................................. 49
5.2.1 Include-Dateien ..................................................................................... 49
5.2.2 JavaBeans in JSP-Seiten...................................................................... 50
5.2.3 Datenbankverbindung ........................................................................... 51
5.2.4 Zugangskontrolle .................................................................................. 51
5.2.5 Label ..................................................................................................... 52
5.3 Modul Titration ............................................................................................. 53
5.3.1 Messdatenerfassung ............................................................................. 53
5.3.2 Titrationsverwaltung .............................................................................. 71
6 Test ................................................................................................................... 81
6.1 Verifikation mit JUnit Tests .......................................................................... 82
6.2 Validierung des Moduls Titration ................................................................. 85
7 Fazit und Ausblick ............................................................................................. 87
8 Abbildungsverzeichnis ....................................................................................... 89
VIII
9 Listingverzeichnis .............................................................................................. 90
10 Tabellenverzeichnis ........................................................................................ 91
11 Literaturverzeichnis ......................................................................................... 92
1
1 Einleitung
In diesem Abschnitt der Bachelorarbeit erfolgt ein kurzer Einblick in das
Unternehmen Miele und in die Abteilung Konstruktion und Entwicklung.
Anschließend wird der Hintergrund und die Motivation sowie die Zielsetzung der
Arbeit beschrieben und eine kurze Erläuterung zur Gliederung gegeben.
1.1 Unternehmensprofil
Die Firma Miele & Cie. KG wurde am 01. Juli 1899 von Carl Miele und Reinhard
Zinkann gegründet. Das Unternehmen begann zunächst mit der Fertigung von Milch-
zentrifugen in Herzebrock bei Gütersloh. Im Laufe der Zeit spezialisierte sich die
Firma Miele auf die Produktion von Haushaltsgeräten. Heute ist Miele einer der
führenden Hersteller in diesem Produktbereich. „Immer Besser“, so lautet das
Firmenmotto von Miele. Seit der Gründung des Unternehmens haben Qualität und
Langlebigkeit der Produkte die höchste Priorität. [1]
Die Produktpalette umfasst neben Geräten zur häuslichen Wäschepflege, wie
Waschvollautomaten, Wäschetrockner und Bügelmaschinen auch Küchengeräte, wie
Geschirrspüler, Herde, Backöfen, Dampfgarer, Kochfelder, Kühl- und
Gefrierschränke, Dunstabzugshauben, Mikrowellen, Kaffeevollautomaten und
Staubsauger. Zudem bietet Miele die meisten der oben aufgezählten Geräte auch in
Gewerbeversionen für den professionellen Einsatz an. Im Gütersloher Hauptwerk
werden derzeit jährlich knapp eine Million Waschautomaten, eines der Kernprodukte,
in verschiedenen Modellen, Ausstattungen und Ländervarianten produziert. [2]
Das Familienunternehmen Miele ist an insgesamt elf Standorten vertreten, von
denen acht Werke innerhalb Deutschlands und jeweils eins in Österreich, Tschechien
und China liegen. Es werden zurzeit ca. 16.600 Mitarbeiter (Stand: Juni 2010), davon
mehr als 10.000 in Deutschland, beschäftigt. [1]
1.2 Abteilung KEW und LD
2
Mit eigenen Vertriebsgesellschaften in 37 Ländern und durch zusätzliche Importeure
ist Miele auf der ganzen Welt vertreten. Im Geschäftsjahr 2009/2010 wurde ein
Umsatz von 2,83 Milliarden Euro erzielt. Das Unternehmen gehört seit der Gründung
1899 den Inhaberfamilien Miele und Zinkann, heute bereits in der vierten Generation.
[1]
1.2 Abteilung KEW und LD
Die Gruppe Labordienstleistungen (LD) ist der Konstruktion und Entwicklung (KEW)
im Werk Gerätefertigung in Gütersloh untergeordnet. Es werden für die gesamte
KEW Messgeräte und Software bereitgestellt und komplette Mess- bzw. Prüfplätze
von der Gruppe LD eingerichtet. Des Weiteren bietet die Gruppe LD einige
datenbank-basierende Dienstleistungen zur Speicherung von Messdaten und zur
Zustands-visualisierung der Prüfplätze an. Der Second Level Support für IT-
Probleme innerhalb der KEW wird ebenfalls von der Gruppe LD abgedeckt.
Im Bereich Labordienstleistungen wird meine Bachelorarbeit durchgeführt.
1.3 Hintergrund und Motivation
In der Firma Miele & Cie. KG werden, wie in zahlreichen anderen Unternehmen
auch, Labore zur Entwicklung von neuen Produkten sowie zur Weiterentwicklung und
Qualitätssicherung bereits bestehender Produkte betrieben. In diesen Laboren finden
sowohl Prüfungen von Geräten während der Entwicklung als auch serienbegleitende
Prüfungen statt. Dazu zählen auch Langzeitprüfungen, wie z.B. 5.000 Waschzyklen
über ca. 2 Jahre für einen Waschautomaten. Es resultieren daraus große Mengen an
Messdaten, welche dauerhaft, effizient und widerspruchsfrei gespeichert und
verwaltet werden müssen.
Um die einzelnen Prüfungen und die damit anfallenden Messdaten einfacher und
strukturierter zu verwalten, wird zurzeit ein neues und für alle Labore identisches
System (ProLab) zur Durchführung und Verwaltung der Prüfungen entwickelt.
1.4 Zielsetzung
3
Die Verwaltung der Prüfaufträge geschieht mit Hilfe der Software Labordatenbank.
Diese wurde von der Firma Werum Software & Systems AG, welche sich auf
Messdatenmanagementsysteme und kundenspezifische IT-Lösungen spezialisiert
hat, in Lüneburg entwickelt. [3]
Der Labormitarbeiter arbeitet mit der Software ProLab, die ihn bei der Durchführung
der Prüfung unterstützt. ProLab ist eine Eigenentwicklung der Firma Miele und wird
derzeit erweitert.
Unter den vielen Laboren ist das Labor Verfahrensprüfung für die Titrationsprüfung
und der Erfassung der Titrationsmessdaten zuständig. Die Messdatenerfassung ist
Kernpunkt meiner Bachelorarbeit.
1.4 Zielsetzung
Diese Arbeit befasst sich mit dem Labor Verfahrensprüfung, speziell mit der Prüfung
Titration. Im Folgenden geht es um die Umstellung einer zuvor manuellen Erfassung
von Titrationsmessdaten auf eine teilweise automatisierte Erfassung und Verwaltung
dieser Daten mit Hilfe der Software-Lösung ProLab. Die Realisierung erfolgt als ein
webbasiertes Workflow-Modul, welches in das ProLab-System eingebunden wird.
1.5 Gliederung der Arbeit
Auf den folgenden Seiten werden zunächst die Grundlagen und Techniken erläutert,
die für die Realisierung des Projekts benötigt werden. Im Anschluss erfolgt eine
Analyse der Prüfungsumgebung und der derzeitigen Vorgehensweise eines
Labormitarbeiters beim Prüfungsverfahren Titration. Des Weiteren wird der
bestehende Prüfprozess bewertet und ein Konzept zur Umstellung des Prozesses
auf das neue System ProLab vorgestellt. Zum Schluss werden die Implementierung
des Konzepts sowie die bei der Realisierung angewendeten Testverfahren erläutert.
4
2 Grundlagen
Um ein Software-Modul zur Erfassung und Auswertung von Titrationsmessungen in
einer zentralen Webanwendung wie ProLab konzeptionieren und realisieren zu
können, werden verschiedene Sprachen und Technologien verwendet. Diese
grundlegenden Techniken sollen in diesem Abschnitt der Arbeit kurz erläutert
werden.
2.1 Miele Prüfungsverwaltungssystem
Wie bereits zu Beginn der Arbeit erwähnt, werden bei Miele zahlreiche Prüfungen in
den Laboren durchgeführt. Dabei werden zum einen Prüfungen von Seriengeräten
durchlaufen, wie z.B. das Prüfen der Lebensdauer und Waschwirkung für die
Qualitätssicherung, und zum anderen Prüfungen im Bereich der Forschung, um neue
Entwicklungen zu testen und näher zu untersuchen.
Prüfaufträge werden im System Labordatenbank (LabDB) und die zu einem
Prüfauftrag gehörenden Prüfungen im System ProLab verwaltet. Beide Systeme
sollen zunächst einmal erläutert werden.
2.1.1 LabDB
Von der Firma Werum wurde eine auf der Hypertest-Plattform [4] basierende
Software für das Unternehmen Miele entwickelt, welches die Verwaltungsebene als
Prüfauftragsverwaltungssoftware abdeckt. Diese Software heißt Labordatenbank
oder kurz: LabDB (s. Abb. 2.1 - Miele Labordatenbank).
Die Hypertest-Plattform kommt in einigen Laboren, wie z.B. der Autoindustrie oder
Luftfahrtindustrie, zum Einsatz und wurde speziell zur Verwaltung von Prüfaufträgen
und allen dazugehörigen Komponenten, wie Prüfobjekten oder Prüfreihen,
entworfen. Des Weiteren sind eine Benutzerverwaltung und ein rollenbasiertes
Rechte-Management integriert. Die Rollen entsprechen den Aufgaben der
Mitarbeiter. So existieren z.B. Rollen für Auftragnehmer und -geber oder verschie-
dene Rollen zur Stammdatenpflege.
2.1 Miele Prüfungsverwaltungssystem
5
Abb. 2.1 - Miele Labordatenbank
Technik
Die grundlegende HyperTest-Software ist eine vollständig in Java entwickelte
Applikation. Diese verwendet das relationale Datenbankmanagementsystem der
Firma Oracle als Persistenzschicht. Darauf aufbauend wurde für das Unternehmen
Miele eine speziell auf die geforderten Geschäftsprozesse angepasste Version der
HyperTest-Software in einer längeren Entwicklungsphase erstellt. Diese Version ist
die LabDB.
Um den Mitarbeitern die LabDB zur Verfügung stellen zu können, wird die Applikation
über den Java-Webstarter ausgeführt. Dieser ermöglicht das Starten von Java-
Anwendungen über ein Netzwerk mit Hilfe eines Webbrowsers. Die Java-
Anwendungen selbst benötigen dabei keinen Browser um lauffähig zu sein, da diese
auf der Java Virtual Machine lokal ausgeführt werden können.
Der Java-Webstarter lädt die entsprechende Anwendung, in unserem Fall die LabDB,
vom Server und startet sie lokal auf dem benötigten System. Dabei wird vorher
geprüft, ob bereits eine Kopie der Anwendung auf dem lokalen System vorliegt und
ob diese Version sich im aktuellen Zustand befindet.
2.1 Miele Prüfungsverwaltungssystem
6
Sind beim Start der Anwendung die serverseitige und die lokale Version identisch,
dann wird die lokale Version sofort gestartet. Im anderen Fall findet eine
Aktualisierung der lokalen Version statt, bei der ein Download auf das lokale System
erfolgt. Dieses Verfahren vereinfacht die Pflege der Anwendung, da Aktualisierungen
nur an einer Stelle durchgeführt und nicht an viele Rechner verteilt werden müssen.
Die Oracle-Datenbank, die der LabDB zugrunde liegt, wird von der zentralen Miele IT
zur Verfügung gestellt.
Funktionsweise
Die Nutzung der LabDB erfolgt hauptsächlich von Auftraggebern, z.B. anderen
Laboren. Der Auftraggeber erstellt zunächst einmal einen Prüfauftrag in der LabDB.
In dem Prüfauftrag werden zum einen die Prüfaufgabe und zum anderen die
Verwaltungsdaten wie Innenauftrag oder Zieltermin festgelegt. Dabei wählt der
Auftraggeber aus einem bereits vorgegebenen Katalog von möglichen Aufgaben die
entsprechende Prüfaufgabe aus.
Solch einem Prüfauftrag muss der Auftraggeber mindestens ein Prüfobjekt zuweisen.
Dabei kann er ein bereits existierendes oder ein ganz neues Prüfobjekt, welches
geprüft werden soll, erstellen. Es ist jedoch nicht möglich ein Prüfobjekt zur gleichen
Zeit mehreren Prüfaufträgen zuzuordnen. Das Prüfobjekt kann ein vollständiges
Gerät oder ein bestimmter Teiles eines Gerätes sein.
Jedem Prüfobjekt wird wiederum wenigstens eine Prüfreihe zugewiesen. In dieser
wird unter anderem der Prüfplatz, an dem die durchzuführenden Prüfungen
stattfinden, spezifiziert.
Zum Schluss werden die Prüfungen der entsprechenden Prüfreihe zugeordnet. Die
Abbildung 2.2 soll den hierarchischen Aufbau eines Prüfauftrags verdeutlichen.
2.1 Miele Prüfungsverwaltungssystem
7
Prüfauftrag
Prüfobjekt 2
...
Prüfobjekt 1
Prüfreihe 1
Prüfreihe 2
...
Prüfung 1
Prüfung 2
...
Abb. 2.2 - Hierarchischer Aufbau eines Prüfauftrags
2.1 Miele Prüfungsverwaltungssystem
8
2.1.2 ProLab
Die entsprechende Applikation für den Labormitarbeiter ist die Software ProLab
(Provo en Laboratorio, Prüfungen im Labor). Diese ist kongruent zur Labordatenbank
aufgebaut und dient zur Unterstützung der Prüfungsdurchführungen. Es bietet dem
Labormitarbeiter Informationen zur Prüfung und ermöglicht das Einbinden von
Messwerten und Ergebnissen.
Abb. 2.3 - Miele ProLab-System
Technik
ProLab ist als eine webbasierte Anwendung konzipiert, bei der die Programmier-
sprachen Java und JavaServer Pages (JSP) eingesetzt werden. Die Anwendung
besteht aus mehreren einzelnen Modulen, die zusammen das System ProLab
ergeben. Als Application-Server wird ein Apache Tomcat-Server verwendet (s.
Kapitel 2.3.1).
2.1 Miele Prüfungsverwaltungssystem
9
Die Kommunikation zwischen der LabDB und ProLab erfolgt mit Hilfe des Java
Messaging System (JMS). Der JMS-Provider ist der JBoss-Application-Server der
Firma Redhat. [5] Als Datenbank bzw. Persistenzschicht dient ProLab eine Informix-
Datenbank (s. Kapitel 2.3.2). Des Weiteren verwendet ProLab eine Laufzeit-
umgebung (XulRunner), die stets die gleiche Funktionalität und das gleiche
Aussehen der Anwendung garantiert.
Die Informix-Datenbank ist auf einem Cluster aus zwei Servern installiert. Dies dient
dem Zweck der Ausfallsicherheit, sodass das System, trotz Ausfall eines der Server,
weiterhin verfügbar ist. Von den zwei Servern ist jeweils nur einer aktiv. Die
Datenbank wird über eine interne Netzwerkverbindung ständig synchron gehalten.
Außerdem dient die Leitung als Kommunikationsleitung zur Überprüfung der Aktivität
des Rechners. Fällt der aktive Server nun aus, übernimmt der andere sofort seine
Aufgaben. Meldet sich der zuvor ausgefallene Server als betriebsbereit zurück, dann
werden die Datenbanken sofort synchronisiert und der Ausgefallene übernimmt die
Rolle des Backup-Servers.
Funktionsweise
Der Labormitarbeiter kann anhand der ProLab-Software Prüfungen zu den
entsprechenden Prüfreihen anlegen und durchführen. Die Ergebnisse und
Auswertungen können als Datei einer Prüfung zugeordnet werden. Bei Abschluss
einer Prüfung werden die Änderungen der LabDB mitgeteilt und synchronisiert. Es
können aber auch Zwischenergebnisse einer noch nicht abgeschlossenen Prüfung
an die LabDB gesendet werden.
Des Weiteren werden die Mitarbeiter-Stammdaten aus der LabDB in das ProLab-
System importiert, so dass jeder Benutzer, der einmal am Hypertest-System
angemeldet war, auch Zugriff auf ProLab hat. Ein Rechtesystem ist aus den
verschiedenen Bereichen und Kostenstellen bei Miele abgeleitet und ist mit dem
Rollensystem in der LabDB zu vergleichen.
2.1 Miele Prüfungsverwaltungssystem
10
Funktionsweise zwischen LabDB und ProLab
Die Abbildung 2.4 soll die Funktionsweise zwischen der LabDB und ProLab
verdeutlichen.
Abb. 2.4 - Funktionsweise zwischen LabDB und ProLab
2.2 Sprachen
11
2.2 Sprachen
In diesem Teilkapitel sollen die für die Realisierung des Projekts benötigten Sprachen
kurz erläutert werden. Die verwendeten Sprachen sind dabei zum einen
Programmiersprachen und zum anderen beschreibende bzw. auszeichnende
Sprachen.
2.2.1 Java
Java ist eine objektorientierte Programmiersprache, die Anfang der 90er Jahre in den
Entwicklungszentren der Firma Sun entstand. Zwar weist sie Ähnlichkeiten mit
Sprachen wie C, C++ und Objective C auf, dennoch basiert sie nicht auf diesen. Eine
Besonderheit von Java ist die Art, in der ein Programm übersetzt und ausgeführt
wird. Ein Java-Programm wird zuerst von einem Compiler in ein Binärformat, den
Bytecode, übersetzt. Dieser Bytecode wird dann von einer Java Virtual Machine
(JVM) ausgeführt. Die Virtual Machine besteht hauptsächlich aus einem Interpreter
und ist auf allen wichtigen Betriebssystemplattformen vorhanden. Wichtige Elemente
von Java sind die sichere Ausführung von Programmen über Netzwerke und die
(volle) Portabilität der erstellten Programme im Binärformat. [6]
2.2.2 HTML
HTML steht für Hypertext Markup Language und ist eine Auszeichnungssprache.
Auszeichnende Sprachen beschreiben die Daten, die verarbeitet werden. Dies
geschieht durch Steuerzeichen und –befehle (Tags), die neben dem eigentlichen
Inhalt im Dokument eingebettet sind. Dadurch erreicht die Sprache auch eine
Plattformunabhängigkeit.
HTML dient zur Strukturierung von Inhalten im World Wide Web (www) und wurde
1989 von Tim Berners-Lee am CERN entworfen.
Dabei geht es nicht darum, den Text exakt zu formatieren; es werden die einzelnen
Elemente (Überschriften, Tabellen, Eingabefelder usw.) definiert und deren
Reihenfolge bestimmt. Das Textdokument lässt sich außerdem in einzelne Bereiche
aufteilen.
2.2 Sprachen
12
Beschreibende Informationen werden in Tags angegeben. Oft wird der Inhalt
zwischen einem öffnenden und einen schließenden Tag aufgeführt. Ein Beispiel
könnte folgendermaßen aussehen: <H1>Hallo Welt!</H1> und in einem Web
Browser den gewünschten Text als Überschrift ohne die Tags darstellen. [7]
Weiterhin zeichnet sich HTML dadurch aus, dass man an die feste Struktur des
Werkes nicht gebunden sein muss. Durch Verweise in einem Text kann der Benutzer
an bestimmte Stellen innerhalb des Dokuments springen. Des Weiteren sind
Sprünge von einem Dokument in ein anderes möglich. Daraus ergibt sich der Vorteil,
dass der Benutzer schnell zu den Stellen gelangt, die für ihn von Interesse sind.
Solche Verweise auf andere Dokumente und Textstellen werden Links genannt.
2.2.3 CSS
Das in HTML fehlende Werkzeug zur Formatierung des Dokuments liefern die
Cascading Stylesheets (CSS). CSS ist eine Stilsprache, die es ermöglicht,
strukturierte Dokumente zu formatieren. [8]
Nachdem 1994 auf einer Konferenz - Mosaic and the Web in Chicago - ein Vorschlag
zur Einführung eines CSS Standards gemacht wurde, hat das World Wide Web
Consortium (W3C, Gremium für Internettechnik) das CSS Level 1 als Standard 1996
veröffentlicht.
2.2.4 JSP
JavaServer Pages (JSP) ermöglichen das Server-seitige, dynamische Generieren
von Webseiten in HTML. JSP sind Bestandteil der Java 2 Enterprise Edition (J2EE),
die dazu dient, große und verteilte Anwendungen zu entwickeln.
Grundlage dabei ist das Einbetten von Java-Code mit Hilfe spezieller Tags in den
statischen HTML-Seiten. Dabei kann kein Standard-Webserver mehr zum Einsatz
kommen. Dieser würde die Tags nicht erkennen und sie als normalen Text an den
Client senden. Stattdessen wird ein Application-Server verwendet. Dieser erzeugt
aus der JSP einen Java-Quellcode, kompiliert diesen und führt ihn in einer JVM aus.
[9] Der genaue Ablauf des Lebenszyklus einer JSP wird im Folgenden betrachtet.
Bei der Ausführung durchläuft eine JSP drei Phasen [10]:
2.2 Sprachen
13
Übersetzungsphase
In dieser Phase wird aus einer JSP-Seite ein Java-Quellcode, welches einem Servlet
entspricht, generiert. Als Servlets bezeichnet man Java-Klassen, deren Instanzen
innerhalb eines Java-Webservers Anfragen von Clients entgegennehmen, bearbeiten
und beantworten.
Das Generieren des Servlet-Quellcodes übernimmt der Application-Server. Dies
geschieht zum einen beim allerersten Aufruf einer JSP-Seite und zum anderen wenn
der Zeitstempel des JSP-Quellcodes neuer ist als der Zeitstempel des bereits
generierten Servlet-Quellcodes. Eine Änderung an einer JSP führt also stets zu einer
neuen Erzeugung des Servlet-Quellcodes.
Dabei werden in dieser Phase des JSP-Lebenszyklus vom Übersetzer nur die Fehler
erkannt, die direkt mit der JSP-Syntax zusammenhängen. Im Java-Code selbst
enthaltene Fehler werden hier noch nicht aufgezeigt. Somit ist die Fehleranzeige in
der Übersetzungsphase und der folgenden Kompilierungsphase unterschiedlich
detailliert.
Kompilierungsphase
In der Kompilierungsphase startet der Tomcat-Server den Java-Compiler Jasper, um
aus dem generierten Servlet-Quellcode eine Java-class-Datei zu erzeugen.
Erst in dieser Phase des JSP-Lebenszyklus werden Fehler innerhalb eines Java-
Codes einer JSP gefunden. Zu den Fehlern zählen z.B. nicht vorhandene Klassen,
die jedoch per import-Statements in einer JSP referenziert werden, oder allgemeine
Java-Syntax-Fehler. Da die Übersetzung und Kompilierung für den ersten Aufruf der
Seite vergleichsweise viel Zeit in Anspruch nehmen, gibt es auch die Möglichkeit,
diese beiden ersten Phasen mit Hilfe spezieller Precompilation-Tools zusammen-
zufassen. Wird die Seite ein zweites Mal aufgerufen, entfallen die ersten zwei
Phasen und die Anzeige erscheint wesentlich schneller.
2.2 Sprachen
14
Ausführungsphase
Die kompilierten Class-Dateien werden, wie jedes Java-Programm, in einer Java-
Virtual-Machine ausgeführt. Beim Application-Server Tomcat ist dies der Container
Catalina.
Zum Laden der benötigten Klassen besitzt jede virtuelle Maschine einen Classloader.
Da auch der Servlet-Container in einer JVM abläuft, muss auch für die Servlets
zunächst der entsprechende Byte-Code in den Arbeitsspeicher geladen und dann ein
passendes Objekt instanziiert werden, bevor es aufgerufen wird.
2.2.5 SQL
Mit Hilfe der Structured Query Language (SQL) lassen sich Anfragen an
Datenbanken stellen. Dabei ist es möglich, neue Daten in die Datenbank schreiben
zu lassen, sie zu ändern bzw. zu aktualisieren und sie wieder auszulesen. Auch das
Anlegen von Tabellen und das Verknüpfen der Daten von verschiedenen Tabellen ist
so realisierbar. Eine Zugriffsverwaltung auf die Tabellen ist ebenfalls integriert. SQL
ist einer der verbreitetsten Standards, um eine Client-Server-Kommunikation mit
Datenbanken zu ermöglichen und bietet somit eine Möglichkeit der Kommunikation
ohne Beachtung der darunterliegenden Software. [11]
Die Semantik der Sprache ist stark an die englische Sprache angelehnt. Sie gliedert
sich in drei Gruppen:
Definition des Datenbankschemas,
Datenmanipulation und Abfrage,
Rechteverwaltung.
Definition des Datenbankschemas
Das Datenbankschema legt fest, welche Daten in einer Datenbank in welcher Form
gespeichert werden können und welche Beziehungen zwischen den Daten bestehen.
Speziell bei relationalen Datenbanken legt das Schema die Tabellen und deren
Attribute sowie, zur Sicherstellung der Konsistenz, die Integritätsbedingungen fest.
2.2 Sprachen
15
Dabei werden die Primärschlüssel und Fremdschlüsselbeziehungen festgelegt.
Listing 2.1 - Beispiel eines Create-Befehls
Abb. 2.5 - Beispiel einer Relation
Listing 2.1 zeigt den Befehl zum Anlegen einer Tabelle (Relation). Sie ist über die
sechs Spalten (Attribute) ID, Name, Postleitzahl, Wohnort, Strasse und Hausnummer
definiert. Die Attribute ID und Postleitzahl vom Typ SMALLINT UNSIGNED fassen
Werte von 0 bis 65535. Das Kommando NOT NULL in der Definition der Attribute
besagt, dass die entsprechende Spalte mit Werten gefüllt werden muss (Pflichtfeld),
sobald ein Datensatz (Tupel) in einer neuen Zeile angelegt wird. Attribute vom Typ
VARCHAR (40) nehmen eine beliebige Zeichenkombination mit der maximalen
Länge von 40 Zeichen auf. Als Primärschlüssel wird das Attribut ID definiert. Anhand
eines Primärschlüssels lässt sich ein Datensatz innerhalb einer Relation eindeutig
bestimmen, wobei er auch über mehrere Attribute definiert sein kann. Über die
Befehle alter bzw. drop lassen sich die mit dem Befehl create erzeugten Schemata
ändern bzw. löschen.
CREATE TABLE Person(
ID SMALLINT UNSIGNED NOT NULL,
Name VARCHAR (40) NOT NULL,
Postleitzahl SMALLINT UNSIGNED,
Wohnort VARCHAR (40),
Strasse VARCHAR (40),
Hausnummer VARCHAR (40),
PRIMARY KEY (ID)
);
2.2 Sprachen
16
Datenmanipulation und Abfrage
Um in vorhandenen Tabellen Daten einzufügen, zu manipulieren oder zu löschen,
gibt es die Befehle insert, update und delete. Ein typisches Statement zur Datenspei-
cherung in einer Tabelle zeigt Listing 2.2.
Listing 2.2 - Beispiel eines Insert-Befehls
Dabei wird in die Tabelle Person, die im vorangegangen Beispiel angelegt wurde, ein
Datensatz eingefügt.
Der Befehl in Listing 2.3 hat genau den zuvor eingegebenen Datensatz als Ausgabe.
Listing 2.3 - Beispiel eines Select-Befehls
Die Befehle DELETE und UPDATE löschen bzw. verändern einen Datensatz, wobei
über die WHERE-Klausel der exakte Datensatz bzw. die Gruppe von Datensätzen
spezifiziert wird. Soll der Inhalt einer Tabelle vollständig gelöscht werden, kommt der
Befehl TRUNCATE zum Einsatz.
Rechteverwaltung
Um eine rudimentäre Rechteverwaltung zu ermöglichen, können einzelnen Benut-
zern oder Gruppen Lese- und Schreibrechte auf die Relationen bzw. Views gegeben
oder entzogen werden. Dieses wird über die Befehle GRANT und REVOKE
ermöglicht. Listing 2.4 zeigt, wie dem Benutzer meier ein lesender und ändernder
Zugriff an der Tabelle Person gegeben wird, Listing 2.5 verdeutlicht wie er ihm wieder
entzogen wird.
Listing 2.4 - Beispiel eines Grant-Befehls
Listing 2.5 - Beispiel eines Revoke-Befehls
INSERT INTO Person
(ID , Name, Postleitzahl, Wohnort, Strasse, Hausnummer )
VALUES (4, 'Otto', 48565,'Steinfurt', 'Buchenweg', '14a');
SELECT * FROM Person WHERE ID=4;
GRANT SELECT, UPDATE ON TABLE Person TO meier;
REVOKE * ON TABLE Person FROM meier;
2.3 Server und Applikationen
17
2.3 Server und Applikationen
Neben den bereits vorgestellten Sprachen und Umgebungen, die in dieser Arbeit zur
Anwendung kommen, werden auch einige Applikationen und Server mit
verschiedenen Aufgaben eingesetzt. Diese werden auf den folgenden Seiten
vorgestellt.
2.3.1 Apache Tomcat
Der Web-Application-Server Tomcat ist eine offizielle Referenz-Implementierung für
die von der Firma Sun Microsystems entwickelte Java-Servlet- und JavaServer-
Pages-Technologie [12]. Tomcat wird in einer offenen und frei zugänglichen
Umgebung entwickelt und ist unter der Apache-Software-Lizenz eingeführt worden.
Ein Web-Application-Server ersetzt den normalen Web-Server. Der Web-Server
würde die in die JSP-Dateien integrierten JSP-Tags als normalen Text ausgeben.
Der Apache Tomcat-Server erkennt diese korrekt als Java- bzw. JSP-Code und führt
sie entsprechend aus. In Kapitel 2.2.4 wurde bereits die Abarbeitung einer JSP
erläutert. Diesen Prozess übernimmt der Application-Server.
Auf Grund der schlechten Arbeitsgeschwindigkeit und der damit begrenzten
Einsatzszenarien, die Tomcat anfangs ermöglichte, wurde die Architektur in der
Version 4 vollständig überarbeitet. Tomcat 6 ist zurzeit die aktuelle Version. Die
Architektur dieses Systems basiert auf einer ineinander geschachtelten
hierarchischen Struktur mit verschiedenen Objekten. Dabei werden die einzelnen
Elemente voneinander unterschieden. Komponenten (Components) stehen in starrer
Beziehung mit anderen Komponenten. Komponenten, die weitere Komponenten
enthalten können, werden Container genannt. Ist es nicht möglich weitere Elemente
in ihnen anzuordnen, sind es so genannte eingebettete Komponenten. Abbildung 2.6
zeigt die Struktur des Tomcat-Application-Servers. [13]
2.3 Server und Applikationen
18
Folgende Component-Elemente existieren:
Server,
Service,
Engine,
Host,
Context.
Abb. 2.6 - Struktur des Tomcat-Applikation-Servers
Des Weiteren gibt es die folgenden eingebetteten Komponenten:
Connector,
Logger,
Valve,
Realm.
Im Folgenden werden die Komponenten kurz erläutert.
2.3 Server und Applikationen
19
Server
Der Server ist eine einzelne Instanz des eigentlichen Tomcat-Servers.
Sollten mehrere Server-Instanzen vom Anwender, z.B. für verschiedene Kunden,
benötigt werden, lassen sich mehrere Instanzen mit unterschiedlichen
Konfigurationen starten. Jedes der Server-Elemente läuft in einer eigenen JVM.
Somit kann keine Instanz eine weitere beeinflussen. Das Server-Element besitzt
einen Port zur Kommunikation, um die Instanz beenden zu können.
Service
Das Service-Component repräsentiert eine Gruppe von Schnittstellen. Es gruppiert
die verschiedenen Engine-Objekte und entscheidet anhand seiner verschiedenen
Konnektoren, an welche Applikation eine Anfrage weitergeleitet werden muss und
von welcher Applikation eine Antwort zu erwarten ist.
Die verschiedenen Konnektoren bieten zusätzliche Dienste wie etwa Verschlüssel-
ung an.
Mehrere Service-Komponenten können neben einer Server-Komponente stehen.
Connector
Wie bereits beschrieben, bietet ein Connector die Schnittstelle nach außen.
Standardmäßig ist das ein HTTP-Port für die Verbindung mit einem Web-Browser
des Klienten mit der Webapplikation. Es werden jedoch auch weitere Protokolle wie
HTTPS oder AJP zur Verbindung mit anderen Klienten oder Servern angeboten.
Das Connector-Element ist ein eingebettetes Objekt bzw. Element. Es lassen sich
zudem eigene Connector-Objekte implementieren.
Engine
Die Engine ist ein Container-Element. Dieses Element hat Kindelemente. Das Objekt
untersucht die ankommenden HTTP-Header, die es vom Service-Objekt erhält, und
leitet es an die entsprechende Webapplikation bzw. den entsprechenden virtuellen
Host weiter.
Eine Engine kann mehrere Hosts bzw. Contexts (Webapplikationen) beinhalten.
2.3 Server und Applikationen
20
Realm
Ein Realm ermöglicht die Benutzer-Authentifikation am System. Ist dieses der Engine
zugeordnet, nutzen alle Hosts bzw. Contexts die gleichen Ressourcen des Realms.
Durch Verlagern des Realms in den Host oder die Webapplikation lassen sich die
Ressourcen besser trennen. Es ist zudem möglich, neben der Engine den
darunterliegenden Objekten einen Realm zuzuweisen. Diese Zuordnungen über-
schreiben die jeweils darüberliegenden.
Es kann gegen Text-Dateien, LDAP-Server oder gegen das Windows-Netzwerk
authentifiziert werden.
Valve
Die Valves sind eingebettete Komponenten, die eine Filter-Funktion ausüben. Sie
sind wieder verwendbar und lassen sich kombinieren. Die eingehenden Anfragen
werden auf das erste zugeordnete Valve in der Kette geleitet und werden,
entsprechend der Reihenfolge in der Zuordnung, an die folgenden Valves weiter-
geleitet.
Sie ermöglichen ein Single-Sign-On (Einmalanmeldung) am Host und können URIs,
IP-Adressen, Server- Statistiken usw. protokollieren.
Das Hinzufügen eines Valves erhöht die Rechenzeit, die eine Anfrage erzeugt.
Logger
Logger geben Auskunft über den aktuellen Status der Komponenten. Sie können an
der Engine, dem Host oder dem Context platziert sein, wobei ein platziertes Logger-
Objekt an die darunterliegenden Komponenten vererbt wird. Das bedeutet, dass ein
an der Engine platziertes Logger-Element auch den Status oder die Fehler eines
darunterliegenden Context-Elements protokolliert.
Host
Die Host-Komponente ermöglicht das Nutzen verschiedener virtueller Web-Server
auf einem Rechner. Diese können anhand von verschiedenen IP-Adressen oder
ihres Host- und Domain-Namens unterschieden werden.
Der Host ist ein Kindelement der Engine, wobei diese natürlich mehrere
verschiedene Host-Definitionen beinhalten kann.
2.3 Server und Applikationen
21
Context
Der Context ist die eigentliche Web-Anwendung. In ihr werden alle benötigten
Methoden und Klassen implementiert.
Auch der Context ist als Container ausgelegt und trägt als Kindelement z.B. die
Servlets.
2.3.2 Informix Datenbank
Zur dauerhaften Datenhaltung, also als Persistenzschicht, wird in ProLab eine
Informix Dynamic Server (IDS) Datenbank genutzt.
In Datenbanken können Daten in Strukturen verwaltet werden, die denen der realen
Welt ähneln. Es werden z.B. Daten über ein Produkt und seine Eigenschaften
gesammelt. Diese lassen sich dann miteinander verknüpfen. Außerdem lassen sich
verschiedene Anwendungen so entwickeln, dass sie auf eine gemeinsame
Datenbasis, nämlich die Datenbank, zugreifen. Sie bieten in diesem Fall nur
unterschiedliche Sichten auf die Daten. So ist auch ein Parallelbetrieb sinnvoll
nutzbar und geänderte Daten stehen sofort jeder Anwendung zur Verfügung, ohne
dass die Änderung auf verschiedene Systeme repliziert werden muss.
Datenbanken tragen somit zur Vermeidung von Redundanzen bei. Anwendungs-
programmierer müssen sich bei der Entwicklung der Applikationen nicht um die
Datenablage, die vom Filesystem abhängig ist, kümmern. Es lassen sich jederzeit
flexible neue Anfragen an die Datenbank richten. Ein weiterer wichtiger Punkt ist,
dass die Datenbank für die Integrität der Daten sorgt. Es lassen sich über Constraints
(Zwangsbedingungen) Abhängigkeiten so definieren, dass dafür gesorgt wird, dass
z.B. beim Löschen einiger Datensätze andere Datensätze, die im Bezug zu den
löschenden Datensätzen stehen, mitentfernt werden oder zumindest diese
Abhängigkeiten aufgelöst werden.
IDS ist ein relationales Datenbank Management System (RDBMS) der Firma IBM.
Ein RDBMS ist ein System, in dem Daten in Tabellen (Relationen) gehalten und
durch Operatoren miteinander verknüpft werden können. Die Spalten der Tabellen
werden oft auch als Attribute bezeichnet. Die Attribute müssen innerhalb einer
Relation eindeutig definiert sein. Die Zeilen repräsentieren jeweils einen Datensatz
und sind somit ein Tupel über die Attribute.
2.3 Server und Applikationen
22
Um Datensätze eindeutig identifizieren zu können, wird ein Schlüssel, der
Primärschlüssel (Primary Key), innerhalb der Relation gesetzt. Er kann über mehrere
Attribute definiert sein, die dann aber in jedem Datensatz der Relation eindeutig sind.
Über diese Schlüssel können dann weitere Operationen leicht abgewickelt werden.
In Kapitel 2.2.5 wurde die Verwendung der Sprache SQL beschrieben, um Anfragen
an die Datenbank richten zu können.
2.3.3 Netbeans
Als Entwicklungsumgebung für Java und JSP wird Netbeans IDE der Firma Sun
Microsystems eingesetzt. Netbeans unterstützt zahlreiche Programmiersprachen,
z.B. Java, C, C++, Fortran oder Groovy. Neben der Unterstützung beim
Programmieren durch Syntax-Highlighting, Code-Vervollständigung, Debugging und
einem GUI-Builder kann Netbeans auch den Software-Entwicklungsprozess durch
ein UML-Modelling-Werkzeug mit Code-Generierung unterstützen. Durch Plugins
lässt sich die Entwicklungsumgebung noch um weitere Funktionalitäten oder
Programmiersprachen erweitern.
23
3 Prozessanalyse
Im folgenden Abschnitt erfolgt eine Analyse des Labors Verfahrensprüfung (VP) und
des derzeitigen Prüfprozesses Titration. Dabei werden die darin enthaltenen Abläufe
und technischen Gegebenheiten aufgezeigt und erläutert. Im Anschluss wird eine
Beurteilung des aktuellen Prüfprozesses durchgeführt und die Problematiken
aufgezeigt.
3.1 Derzeitiger Prüfprozess im Labor VP
Um die Effizienz eines Waschautomaten bezüglich seiner Reinigungsleistung zu
ermitteln, wurde bei der Firma Miele das Labor Verfahrensprüfung (VP) eingerichtet.
Dort werden unter anderem fest definierte Wäscheposten gewaschen und die
Waschwirkung ermittelt. An den einzelnen Wäschestücken aus dem Wäscheposten
sind Textil-Teststreifen mit genormten Anschmutzungen oder Woll-Teststreifen
angenäht. Nach dem Waschvorgang werden diese wieder entfernt und die
verbliebene Verschmutzung sowie das Schrumpfen der Wolle gemessen. Des
Weiteren wird der Restbestand des Spülmittels (Spülwirkung) innerhalb des
Wäschepostens analysiert.
Die für diese Bachelorarbeit relevanten Messungen beziehen sich auf die
Spülwirkung der Wäscheposten.
3.1.1 Datenverarbeitung
Grundlage der gesamten Datenverarbeitung ist eine Sammlung verschiedener Excel-
Dateien. Die Dateien selbst beinhalten unterschiedliche Arbeitsmappen bestehend
aus Tabellen, Reports und Makros, die miteinander verknüpft sind.
Die Dateneingabe in die entsprechenden Tabellen erfolgt durch automatisierte
Prozesse während des Messvorgangs oder manuell durch den verantwortlichen
Sachbearbeiter. Die dabei manuell einzupflegenden Messdaten in die zuständigen
Excel-Dateien werden dem Sachbearbeiter von einem Labormitarbeiter bereitgestellt,
der die Messdaten zuvor am Messgerät abliest oder diese über einen Ausdruck
erhält.
3.1 Derzeitiger Prüfprozess im Labor VP
24
3.1.2 Prozessablauf
Messung der Spülwirkung
Nachdem ein Waschautomat einen Waschvorgang (Waschen der Wäsche mit dem
Waschmittel) abgeschlossen hat, erfolgt im Anschluss ein Spülvorgang, der die
Wäsche vom Waschmittel befreit. Dieser Vorgang wird mit reinem, klarem Wasser
durchgeführt.
Um die Wirkung eines Spülvorgangs prüfen zu können, wird der
Restanteil der Waschlauge in der Wäsche ermittelt. Dazu wird
die Wäsche nach dem Spülvorgang aus dem Waschautomaten
entnommen und in einer separaten Zentrifuge zentrifugiert. Die
dabei aufgefangene Waschlauge (auch Probe genannt) wird im
Anschluss gemessen.
Für die Messung der Probe wird das Titrationsverfahren
angewendet. [14] Dabei wird die Probe durch das Hinzufügen
einer Säurelösung solange versetzt, bis sie einen neutralen PH-
Wert erreicht (s. Abb. 3.1). Die dabei benötigte Menge der
Säurelösung wird für die Bestimmung der Spülwirkung notiert.
Um für die Messung der Spülwirkung einen Referenzwert zu erhalten, wird auch das
reine Wasser, welches für den Spülvorgang verwendet wurde, mit Hilfe des
Titrationsverfahrens gemessen. Das reine Wasser wird dabei Blindprobe genannt.
Auch in diesem Fall wird die benötigte Menge der Säurelösung für die Bestimmung
der Spülwirkung notiert.
Die für einen Spülvorgang gemessenen Lösungen (Probe und Blindprobe) gehören
stets als Paar zusammen und werden einer entsprechenden Prüfung zugeordnet.
Abb. 3.1 -
Titrationsverfahren
3.1 Derzeitiger Prüfprozess im Labor VP
25
Prozess Titration
Der Ablauf der Titrationsprüfung erfolgt in folgenden Schritten:
Zunächst entnimmt der Labormitarbeiter nach dem Vorgang des Waschens und des
Zentrifugierens die Lösung. Dies wird pro Waschgang durchgeführt, so dass z.B. bei
5 Waschvorgängen 5 Lösungen in Glasbehältern entnommen werden. Die
Glasbehälter werden beschriftet, um eine eindeutige Zuordnung der Waschlauge zu
der entsprechenden Prüfung zu gewährleisten. Des Weiteren werden die
entsprechenden 5 Blindproben dazu geholt, die ebenfalls mit einer eindeutigen
Beschriftung am Glasbehälter einer Prüfung zugeordnet sind. Im Anschluss erfolgt
eine Vorbereitung der Proben und Blindproben für den Titrierautomaten.
Der zuständige Labormitarbeiter füllt die Proben und Blindproben der Reihe nach in
kleinere Plastikbehälter um. Die Behälter sind von der Größe passgenau für das
Rondell des Titrierautomaten vorgesehen. Die Füllmenge soll ein Gewicht zwischen
70 und 90 Gramm aufweisen. Die abgefüllten Lösungen werden danach, ebenfalls
der Reihe nach, in das Rondell gestellt. Dabei achtet der Mitarbeiter darauf, dass das
Paar aus Probe und Blindprobe, die zu einer Prüfung gehören, stets nebeneinander
stehen. Nachdem alle Behälter im Rondell platziert wurden, muss der Titrierautomat
für die Messungen vorbereitet werden.
Abb. 3.2 - Titrierautomat mit Rondell
3.1 Derzeitiger Prüfprozess im Labor VP
26
Beim Einrichten der Messvorgänge am Titrierautomaten muss der Labormitarbeiter,
entsprechend der vorher festgelegten Messreihenfolge, die Messabläufe am
Bedienfeld des Titrierautomaten einpflegen. Dazu legt er die Anzahl der zu
prüfenden Lösungen in einer Tabelle (Sample Table) fest. Im Anschluss wählt er zu
den Lösungen die passenden Messmethoden (01_Blind für Blindprobe und
02_Probe für Probe) am Titrierautomaten aus. Zusätzlich müssen noch weitere
Kenndaten eingetragen werden. Die benötigten Kenndaten sind die eindeutigen
Identifikationsnummern der Lösungen. Diese Daten werden in die Felder ID1 und ID2
mit Hilfe der Ziffernblock-Tastatur eingepflegt. Nachdem alle Daten im
Titrierautomaten vorhanden sind, wird der Messvorgang gestartet.
Eine Messung pro Lösung dauert ca. 2 bis 3 Minuten. Das Rondell bietet Platz für 5
Paare bzw. 10 Lösungen, so dass ein kompletter Messvorgang ca. 30 Minuten
andauert. Der komplette Messvorgang muss dabei nicht beaufsichtigt werden.
Anders als in der Reflektionsmessung, bei der die Messdaten automatisch mit Hilfe
einer Messdatenerfassungssoftware als Datei abgespeichert werden, erfolgt die
Ausgabe der Titrationsmessdaten in Papierform. Dabei werden die Messdaten mit
Hilfe eines Thermodruckers, der am Titrierautomaten angeschlossen ist, automatisch
ausgedruckt. Die Ausdrucke erscheinen sofort nach jeder abgeschlossen
Teilmessung (Messung pro Lösung), so dass während des gesamten Messvorgangs
die Ergebnisse der Teilmessungen vom Labormitarbeiter eingesehen und nach
grober Plausibilität geprüft werden können.
Nachdem der komplette Titrationsmessvorgang durchgeführt wurde, sichtet der
Labormitarbeiter die Ergebnisse und überbringt die Ausdrucke dem zuständigen
Sachmitarbeiter. Dieser pflegt die Messdaten manuell in die entsprechende Excel-
Tabelle Prüfungsverwaltung ein und weist die Tabelle dem Prüfauftrag in der
Labordatenbank zu.
Damit ist ein kompletter Messvorgang abgeschlossen und der Titrationsprozess
beginnt wieder von vorne.
3.1 Derzeitiger Prüfprozess im Labor VP
27
3.1.3 Bewertung des aktuellen Prozesses
Mit der Einführung der Auftragsverwaltung LabDB Anfang diesen Jahres (2011) und
der geplanten Einführung im 4. Quartal 2011 des dazugehörigen webbasierten
Laborsystems ProLab, welches sich derzeit noch in der Entwicklungs- und Testphase
befindet, wurden bereits einige Prüfprozesse in die Systeme eingebunden. Dabei ist
das Ziel der Systeme ein möglichst automatisiertes Verfahren der Erfassung,
Verwaltung und Zusammenführung aller Messungen eines Prüfauftrages
durchzuführen.
Das Verfahren der Titrationsprüfung ist jedoch, wie man es bereits in der
Prozessanalyse feststellen konnte, bis auf den Titrationsautomaten selbst
keineswegs automatisiert. Zwei wichtige Faktoren sprechen ganz besonders für die
Umsetzung einer teilweisen Automatisierung.
Zum einen ist die Fehleranfälligkeit sowohl bei der Eingabe der Kenndaten am
Titrierautomaten als auch beim Übertragen der Messdaten vom Ausdruck in die
Excel-Tabellen hoch. Zum anderen ist die manuelle Bearbeitung sehr zeitaufwendig,
sodass ein automatisiertes Verfahren eine enorme Zeiteinsparung einbringen würde.
Dies gab den Verantwortlichen des Labors Verfahrensprüfung und den Miele-
Entwicklern des Laborsystems ProLab den Anlass, auch diesen Bereich des
Prüfprozesses möglichst zu automatisieren.
28
4 Konzeption
Auf Grund der grundsätzlich geplanten Umstellung der Prüflabore auf das neue
System ProLab und der zuvor gewonnen Erkenntnisse im Bereich der Titrations-
messung, soll die Machbarkeit (das Ob) und Realisierung (das Wie) des Projekts
analysiert und konzeptioniert werden.
4.1 Analyse der Technik
Zunächst einmal soll die Arbeitsplatzumgebung und der Titrierautomat innerhalb des
Labors untersucht werden. Bei der Prozessanalyse wurde bereits festgestellt, dass
der Titrierautomat das Hauptaugenmerk darstellt und für die automatisierte
Erfassung der Messdaten von großer Relevanz ist.
Der Titrierautomat „848 Titrino plus“ der Firma Metrohm AG besteht aus folgenden
Komponenten:
Titrierautomat 848 Titrino plus,
Compact Sample Changer, auch Rondell genannt,
USB Thermodrucker Neo’s,
Numerische USB-Tastatur,
Waage,
RS-232/USB Box.
4.1 Analyse der Technik
29
Die Abbildung 4.1 zeigt die ersten 5 Systemkomponenten, die bereits im Labor
Verfahrensprüfung verwendet werden.
Abb. 4.1 - Systemkomponenten v.l.: Drucker, Tastatur, Titrino, Rondel und Waage
In der Abbildung 4.2 ist die RS-232/USB Box sichtbar. Diese Box ist für das
Empfangen der Messdaten vom Titrierautomaten relevant.
Abb. 4.2 - RS232/USB Box
4.1 Analyse der Technik
30
Des Weiteren stellt die Abbildung 4.3 den Aufbau der Systemkomponenten dar.
Titrierautomat Rondell
USB-HUB
Waage
Thermodrucker
NumBlockTastatur
RS232/USB Box
RS232U
SB
USB
USB
RS232
USB
Abb. 4.3 - Aufbau der Systemkomponenten im Labor
4.1 Analyse der Technik
31
4.1.1 Dateneingabe
Die erforderliche Dateneingabe am Titrierautomaten erfolgt sowohl über das
Bedienfeld am Automaten selber als auch über die numerische USB-Tastatur.
Optional kann über eine Messwaage, die ebenfalls über eine USB-Verbindung an
den Automaten angeschlossen ist, das Gewicht der Proben übertragen werden.
4.1.2 Datenausgabe
Die am Titrierautomaten gemessenen Daten werden über den angeschlossenen
Thermodrucker direkt nach der Messung ausgedruckt. Die Übertragung der Daten
geschieht über eine USB-Schnittstelle.
Des Weiteren ist das Auslesen der Messdaten mit Hilfe eines Computersystems über
eine weitere RS-232 Verbindung, dem COM2 Anschluss, möglich. Die Daten werden
als maschinenlesbarer Report mittels der ASCII-Kodierung übertragen. In Listing 4.1
ist ein Auszug des Reports, der auch für Menschen gut lesbar ist, dargestellt.
Listing 4.1 - Reportauszug vom 848 Titrino plus
$S MPL V2
$S Mode 1 04 SET pH V1.0
1 0.0 6.938 0.0000 0.0 23.6
2 2.0 6.917 0.0160 544.0 23.6
3 4.0 6.887 0.0440 904.1 23.6
4 6.0 6.763 0.1300 2651.9 23.6
5 8.0 6.262 0.2300 3140.9 23.6
6 10.0 5.295 0.2960 2756.8 23.6
7 12.0 4.707 0.2980 2045.9 23.6
8 14.0 4.404 0.3000 1491.4 23.6
$E
$E
$S Sensor V1
$S Sensor1 V2
pH-41H00248/0002 pH 99.2 7.086 23.2 2011-08-10
$E
$E
4.2 Anforderungen
32
4.2 Anforderungen
Nach der durchgeführten Prozessanalyse und der Technikanalyse kann die
Machbarkeit zur Einbindung der Titrationsmessungen ins ProLab-System
grundsätzlich als durchführbar eingestuft werden.
Daraufhin wird zunächst ein Lastenheft mit groben Anforderungen definiert. Die
Anforderungen werden durch ein von mir erstelltes Pflichtenheft konkretisiert und
festgelegt.
4.2.1 Konzeptionelle Anforderungen
Folgende Anforderungen werden dabei festgelegt:
Integration der Titration in die ProLab Web-Oberfläche,
Automatische Erfassung der Messdaten,
Suchfunktion und Verwaltung,
Manueller Abbruch und Fehlerinformationen.
Integration der Titration in die ProLab Web-Oberfläche
Der Prozess Titration soll in das System ProLab weitestgehend voll integriert werden.
Dabei sollen die in ProLab allgemein eingesetzten Technologien und Techniken, die
in Kapitel 5.2 genauer erläutert werden, sowie die Aspekte der Benutzerfreundlichkeit
und der Intuitivität (Look and Feel) beachtet und angewendet werden. Eine der
wichtigsten Bedingungen ist das Entwickeln des webbasierten Vorgangs als
Workflow, anhand dessen der Labormitarbeiter die Titrationsmessung Schritt für
Schritt durchführen kann.
Automatische Erfassung der Messdaten
Die bei der Titration anfallenden Messdaten sollen, wie in anderen Modulen des
ProLab-Systems auch, automatisiert erfasst werden. Die Messdaten sollen dabei
nicht mehr wie zuvor in Excel-Tabellen hinterlegt werden, sondern vom
Titrierautomaten empfangen und mit Hilfe der Informix-Datenbank als Datensätze in
die relationalen Datenbanktabellen gespeichert werden. Dabei soll die Eindeutigkeit
einer Messung ständig gewährleistet sein.
4.2 Anforderungen
33
Suchfunktion und Verwaltung
Die Zuweisung einer Prüfung zu den Messdaten ist Grundvoraussetzung zur
Integration des Moduls Titration ins ProLab-System. Dazu ist eine Suchfunktion
innerhalb des Moduls gewünscht, um die Messdaten mit den Prüfungen zu
verknüpfen. Ebenfalls soll eine Verwaltung der erhaltenen Messdaten möglich sein.
Manueller Abbruch und Fehlerinformationen
Ein weiterer wichtiger Punkt der Anforderungen ist das manuelle Abbrechen durch
den Labormitarbeiter während eines laufenden Messvorgangs. Dabei soll der
webbasierte Workflow und die technische Erfassung der Messdaten kontrolliert
gestoppt und mit einer Informationsmeldung zur Startseite des Moduls Titration
gelangen. Des Weiteren sollen die bereits erfolgreich abgeschlossenen
Teilmessungen eines kompletten Messvorgangs nicht verloren gehen, sondern zur
Überprüfung und Verwaltung in der Datenbank vorliegen.
Auch bei unvorhersehbaren Fehlern soll sich die Anwendung weitestgehend
kontrolliert beenden und dem Benutzer eine verständliche Fehlermeldung liefern.
Schlussfolgerung
Aus den oben genannten Anforderungen, wie z.B. der manuellen Messvorbereitung
durch einen Labormitarbeiter, ist nun ersichtlich, dass in diesem Projekt kein
vollautomatisierter, sondern nur ein teilautomatisierter Vorgang erwünscht und
realisierbar ist. Dies erfolgt als webbasierter Workflow. Das Messen der Proben und
das Abspeichern der gewonnen Messdaten soll jedoch vollautomatisiert erfolgen.
4.2 Anforderungen
34
4.2.2 Technische Anforderungen
Folgende Anforderungen wurden dabei festgelegt:
Technische Erfassung der Messdaten,
Analyse des Reports und Erstellung eines Parsers.
Technische Erfassung der Messdaten
Eines der wichtigen Aspekte bei den technischen Anforderungen ist das Erfassen der
Messdaten, die vom Titrierautomaten gesendet werden. Dabei sollen die Daten nicht
direkt vom Titrierautomaten zum PC-System übertragen, sondern über das interne
Netzwerk empfangen werden. Hierzu ist eine technische Lösung nötig, die sowohl
die Netzwerk- als auch die RS-232-Schnittstelle beherrscht und eine Übertragung der
Daten, auch Report genannt, gewährleistet.
Analyse des Reports und Erstellung eines Parsers
Eine weitere technische Anforderung ist das richtige Auslesen und Interpretieren der
über die Schnittstelle übertragenen Daten. Hierzu wird eine Anwendung benötigt, die
die entsprechenden Messdaten aus dem gesamten Report herausfiltert, aufbereitet
und zur Verfügung stellt. Solch eine Anwendung wird Parser bzw. das Vorgehen
parsen genannt. Des Weiteren sollen die aufbereiteten Messdaten zur Sicherung in
die Datenbank gespeichert werden.
4.3 Entwurf
35
4.3 Entwurf
Anhand der zuvor durchgeführten Analyse und der definierten Anforderungen wird
ein Entwurf des Moduls Titration konzeptioniert. Der Entwurf beschäftigt sich
hauptsächlich mit der Entscheidung, wie die Anforderungen optimal umgesetzt
werden können. Das Modul Titration stellt dabei einen webbasierten Workflow dar,
welches den gesamten Prozess der Titration in das ProLab-System integriert.
4.3.1 PC-System & die Schnittstelle Com-Server
In der Firma Miele werden weitestgehend PC-Systeme als ThinClient-Komponente
verwendet. Das ThinClient-Prinzip ist ein Client-Server-Modell, welches einen oder
mehrere relativ leistungsschwache MiniPCs und einen leistungsstarken Server als
Hardware-Landschaft zur Verfügung stellt. Der MiniPC dient als Terminal und ist
grundsätzlich nur für die Ein- und Ausgabe der Daten verantwortlich. Für die
Datenverarbeitung und Datenspeicherung ist der Server zuständig.
Zwei der genannten Anforderungen in diesem Projekt sind das Übertragen der
Messdaten über das interne Netzwerk sowie die Verwendung des Titrations-Moduls
über ein Terminal (ThinClient-Komponente) innerhalb des ProLab-Systems.
Für das Übertragen der Messdaten übers Netzwerk soll die Hardwarekomponente
„Com-Server Highspeed Industry“ von der Firma W&T GmbH verwendet werden.
Diese Komponente verbindet die RS-232-Schnittstelle vom Titrierautomaten mit dem
internen Netzwerk über einen Ethernet-Port. Die Entscheidung für dieses Produkt fiel
zum einen, weil es die Norm sowohl für die Büro- als auch für die Industrieumgebung
einhält und somit für die Labore geeignet ist und zum anderen, weil das Produkt nicht
mehr zusätzlich dazugekauft werden muss, da mehrere solcher Komponenten bei
Miele bereits vorliegen und eingesetzt werden. Des Weiteren bietet der Com-Server
eine komfortable Fernkonfigurierung über den Browser (Web Based Management).
4.3 Entwurf
36
Der Terminal (Monitor, MiniPC, Maus und Tastatur) soll ebenfalls dem Labor zur
Verfügung gestellt werden. Dieser wird im Bereich der Titration neben dem Titrier-
automaten aufgebaut und an das interne Netzwerk angeschlossen.
Die Abbildung 4.4 weist die Systemkomponenten auf, die für die Durchführung des
ProLab-Moduls Titration zusätzlich benötigt werden.
Abb. 4.4 - Com-Server und Terminal im Labor Verfahrensprüfung
4.3 Entwurf
37
Abbildung 4.5 soll den Aufbau der Systemkomponenten verdeutlichen. Der rechte,
gräulich dargestellte Bereich, ist der Bereich der bereits bestehenden
Systemkomponenten. Der linke, bläuliche Bereich stellt die Komponenten dar, die für
die Durchführung des Moduls Titration an die bestehenden Komponenten
angebunden werden müssen.
Titrierautomat Rondell
USB-HUB
Waage
Thermodrucker
NumBlockTastatur
RS232/USB Box
RS232
USB
USB
USB
RS232
USB
Netzwerk
Terminal
Com-Server RS232
LAN
LAN
Abb. 4.5 - Systemkomponenten und Kommunikation
4.3 Entwurf
38
4.3.2 Modul Titration
Anhand der klar definierten Anforderungen ist dem Modul Titration bereits eine
gewisse Richtung für den Entwurf und die Implementierung vorgegeben.
Mit Hilfe des Programms CmapTools wird ein Ablaufdiagramm erstellt, welches den
webbasierten Workflow des Moduls erläutert. Dabei wird eine Interaktion zwischen
dem Labormitarbeiter und dem ProLab-System dargestellt. Die Abbildungen 4.6 bis
4.8 stellen den webbasierten Ablauf des Moduls dar.
Abb. 4.6 - Ablaufdiagramm Titration Teil1
4.3 Entwurf
39
Abb. 4.7 - Ablaufdiagramm Titration Teil2
4.3 Entwurf
41
Synchronisationsvorgang
Die Abbildung 4.6 (Titration Teil 1) des Ablaufdiagramms weißt am Anfang einen
Vorgang auf, der im grundsätzlichen Prozess Titration nicht im Labor Verfahrens-
prüfung vorzufinden ist. Jedoch sind während der Prozess- und der Technikanalyse
die Anforderungen aufgekommen, eine Eindeutigkeit und eine fehlerfreie
Übertragung der Messdaten übers Netzwerk zu gewährleisten. Somit wird, in
Absprache mit dem Auftraggeber, ein Synchronisationsvorgang als Kontrollinstanz
definiert, welcher vor dem eigentlichen Messvorgang in das Titrationsmodul
eingebunden werden soll.
Anhand des vom Titrierautomaten mitgelieferten Benutzerhandbuchs und der
Analyse des Datenausgabestroms (Report) ist bekannt, dass zu jeder Messung zwei
Identifikationsnummern (relative ID und absolute ID) vom Automaten generiert
werden. Die relative ID ist eine Nummer, die bei jeder neuen Messung hochgezählt
und auf dem Ergebniszettel zusätzlich ausgedruckt wird. Erfolgt ein Abschalten des
Titrierautomaten, so geht die aktuelle Zahl verloren und der Titrierautomat beginnt
nach dem Einschalten wieder bei der Zahl 1. Im Gegensatz dazu geht die absolute
ID, bei der die Nummer ebenfalls pro Messung hochgezählt wird, beim Aus- und
Einschalten nicht verloren und garantiert somit stets die Eindeutigkeit einer Probe.
Ein Ausdruck der absoluten ID auf dem Ergebniszettel erfolgt dabei nicht. Des
Weiteren ist das direkte Auslesen der IDs am Titrierautomaten nicht möglich. Es
werden jedoch beide Identifikationsnummern, erst nach einer abgeschlossenen
Messung, im Report über das Netzwerk übertragen und stehen somit dem ProLab-
System zur Verfügung.
Aus den gewonnen Erkenntnissen wird ein Synchronisationsvorgang konzipiert, der
eine Kontrolle der Übertragung von Messdaten gewährleisten soll.
Dazu soll zu den bereits bestehenden Messmethoden 01_Blind und 02_Probe eine
weitere Messmethode 03_Sync am Titrierautomaten hinzugefügt werden. Diese
Methode simuliert am Automaten eine Messung, die ca. 10 Sekunden andauert.
Nach Abschluss der simulierten Messung soll der Titrierautomat die benötigten IDs
als Report übers Netzwerk senden und einen Ausdruck am Thermodrucker
durchführen. Der gesendete Report soll vom ProLab-System empfangen und die IDs
zur Kontrolle ausgegeben werden. Der Labormitarbeiter vergleicht die relative ID auf
dem Ausdruck mit der relativen ID in ProLab und bestätigt bei Gleichheit den
4.3 Entwurf
42
korrekten Synchronisationsvorgang. Gibt es keine Übereinstimmung, so soll der
Vorgang erneut ausgeführt werden können.
Der Synchronisationsvorgang dient somit als Kontrolle der Netzwerkkommunikation
zwischen Titrierautomat und System, die vor jedem kompletten Messvorgang
durchgeführt wird.
Messvorgang
Nachdem ein Synchronisationsvorgang abgeschlossen und als korrekt bestätigt
wurde, erfolgt der eigentliche Messvorgang. Dieser besteht aus mehreren
Messungen und wird durch eine eindeutige Vorgangsnummer identifiziert.
Zunächst wird eine Vorbereitung der Messungen durchgeführt. In dieser Messvor-
bereitung legt der Labormitarbeiter die zu prüfenden Proben im Titrations-Modul fest.
Wie bereits im Kapitel 3.1.2 Prozessablauf erwähnt, werden das Paar aus Probe und
Blindprobe zu einer Prüfung mit einer festgelegten Prüfungsnummer zugeordnet. Der
Mitarbeiter wählt mit Hilfe einer Suchfunktion die Prüfungsnummer aus und weist
diese dem Messvorgang zu. Das ProLab-System erfasst die gewünschte Prüfung
und legt automatisch zwei Messungen, eine für die Probe und die andere für die
Blindprobe, im Messvorgang an. Danach kann der Mitarbeiter weitere Prüfungen
dem Messvorgang zuordnen. Die Abbildung 4.9 soll den Zusammenhang zwischen
Vorgangsnummer, Prüfungsnummer und den Proben zu dem Messvorgang ver-
deutlichen.
Abb. 4.9 - Zusammenhang eines Messvorgangs
4.3 Entwurf
43
Nachdem die Messvorbereitung am ProLab-System abgeschlossen wurde, bereitet
der Labormitarbeiter die Messungen am Titrierautomaten vor und setzt die Proben in
das Rondell des Titrierautomaten ein. Danach kann der Messvorgang durchgeführt
werden. Dazu startet er zunächst den Messvorgang am ProLab-System und im
Anschluss die Messungen am Automaten. Die kompletten Messungen sowie die
Kommunikation zwischen dem Titrierautomaten und dem ProLab-System laufen
dann voll automatisch. Der Labormitarbeiter wird vom ProLab-System informiert,
sobald der komplette Messvorgang durchgeführt wurde. Jedoch kann der Mitarbeiter
schon während des Messvorgangs sehen, ob Teilmessungen abgeschlossen
wurden.
Um den Verlauf einer Messung kontrollieren bzw. verfolgen zu können, wird jeder
Messung ein Status im ProLab-System zugewiesen. Während des laufenden
Messvorgangs können sich die Status ändern und werden aktualisiert im ProLab-
System dargestellt.
Folgende Status werden verwendet:
Statuswert Beschreibung
erfasst Die Vorbedingungsdaten (z.B. Prüfungsnummer und Vorgangsnummer) sind in der Datenbank erfasst.
Messung läuft Es werden die Messdaten zu dem Datensatz gemessen.
Messung beendet Die Messdaten zum Datensatz liegen vor.
freigegeben Die Daten sind als richtig bestätig worden.
deaktiviert Ein anderer Datensatz ist an die zugehörige Prüfung neu hinterlegt worden bzw. der Datensatz ist vom Anwender manuell deaktiviert worden.
Tabelle 4.1 - Status der Messungen im ProLab-System
Bereits abgeschlossene Messungen führen den Status „Messung beendet“ und noch
laufende Messungen den Status „Messung läuft“. Des Weiteren wird automatisch
erkannt, ob es sich bei einer Messung um eine Probe oder Blindprobe handelt,
welche dann im ProLab-System bei der entsprechenden Messung korrekt
eingetragen wird.
4.3 Entwurf
44
Messdatenprüfung
Im Anschluss der abgeschlossenen Messungen müssen die erfassten Messdaten
vom Labormitarbeiter geprüft werden. Dazu soll das Modul eine Übersicht der zuletzt
gemessenen Daten, nach der Vorgangsnummer sortiert, darstellen. Die aktuellsten
Messungen werden dabei in der Übersichtstabelle an oberster Stelle angezeigt. Der
Mitarbeiter vergleicht die Messdaten auf dem Ausdruck mit den Messdaten im
ProLab-System. Sind die Messdaten korrekt, so werden diese mit dem Button
„Speichern“ als Status freigegeben abgespeichert. Bei falsch erfassten Messdaten
kann der Mitarbeiter mit dem Button „Löschen“ den Status der jeweiligen Messung
auf deaktiviert setzten. Wählt der Mitarbeiter den Button „Bearbeiten“, so wird
ebenfalls die jeweilige Messung auf den Status deaktiviert gesetzt und zusätzlich
wird eine neue JSP-Maske aufgerufen. In dieser Maske kann der Mitarbeiter
händisch die richtigen Messdaten einpflegen.
4.3.3 Applikation zur Netzwerkkommunikation
Um die übers Netzwerk gesendeten Messdaten clientseitig zu empfangen, wird eine
Anwendung benötigt, die die gesamte Kommunikation verwaltet. Diese Anwendung
soll in das Modul Titration integriert und an den entsprechenden Seiten ausgeführt
werden. Dazu erfolgt die Realisierung der Anwendung mittels der Programmier-
sprache Java, welche durch eine JavaBean instanziiert und im Tomcat-Application-
Server ausgeführt wird.
Als Entwurf dieser Anwendung wird folgendes Klassendiagramm (Abb. 4.10)
zugrunde gelegt. Das Klassendiagramm ist in 3 grobe Bereiche gegliedert. Der erste,
obere Bereich stellt die wichtigen benötigten Klassen Thread und Socket aus der
Java-Package dar. Der zweite, untere Bereich weist die Klassen DBConnection und
SQLIQuery auf, die aus der Miele-Package stammen. Diese werden für die
Datenbankverbindung und die Datenverwaltung benötigt.
Der dritte, mittlere Bereich stellt die Klassen TitrationStarterBean, TitrationControler
und SocketReader dar, die zur Lösung der Netzwerkkommunikation und zur
Speicherung der Messdaten für das Modul Titration entwickelt werden müssen. In
diesem Abschnitt der Arbeit werden die drei Klassen vorgestellt und kurz erläutert.
Eine detaillierte Beschreibung der Funktionen erfolgt später im Kapitel 5
Implementierung.
4.3 Entwurf
45
Abb. 4.10 - Klassendiagramm Titration
Klasse: SocketReader
Damit man sich beim Übertragen von Daten übers Netzwerk nicht mit verschiedenen
Übertragungsprotokollen wie http, oder noch tiefer, TCP/IP kümmern muss, gibt es
das Software-Modul Socket. Der Socket ist für die grundlegende
Netzwerkkommunikation, d.h. für die Verbindung und für den Datenaustausch,
zuständig. Die Sockets bilden somit eine plattformunabhängige, standardisierte
Schnittstelle zwischen der Netzwerkprotokoll-Implementierung des Betriebssystems
und der eigentlichen Anwendungssoftware.
4.3 Entwurf
46
Als plattformunabhängige Programmiersprache unterstützt Java ebenfalls die
Socket-Programmierung, wobei die Implementierung der Sockets für die verschie-
denen Plattformen über die Klassenbibliotheken der virtuellen Maschine erfolgt.
Der SocketReader hat die Aufgabe, mit Hilfe eines Socket-Objekts eine
Netzwerkverbindung zum Com-Server aufzubauen und die vom Com-Server
gesendeten Daten zu empfangen. Weil die Messdaten in unregelmäßigen Abständen
und mit Wartezeiten von bis zu 4 Minuten pro Messung gesendet werden, soll die
Anwendung dauerhaft im Netzwerk auf dem entsprechenden Port lauschen und
Daten entgegennehmen. Die bereits empfangenen Daten sollen zunächst einmal
zwischengespeichert und dann an die TitrationControler-Anwendung weitergereicht
werden. Damit die Anwendung parallel bzw. nebenläufig zu den anderen
Anwendungen laufen kann, erbt die Klasse SocketReader von der Klasse Thread und
führt die Aufgaben als eigene Thread-Instanz aus.
Klasse: TitrationControler
Die TitrationControler–Anwendung soll für das Entgegennehmen, Aufbereiten und
Speichern der Messdaten zuständig sein. Dabei instanziiert es ein Objekt der Klasse
SocketReader und prüft, ob dieser empfangene Daten für ihn bereithält. Sollten Daten
empfangen worden sein, so nimmt die Anwendung die Daten entgegen, analysiert
sie und bereitet sie für das Speichern in die Datenbank auf. Der Vorgang des
Analysieren und Aufbereiten (Zerlegen und Umwandeln) wird parsen bzw. die
Anwendung Parser genannt.
Das Parsen erfolgt durch vorher definierte Regeln. Dabei werden die Messdaten von
den übrigen Daten, die übers Netzwerk gesendet wurden, herausgefiltert und
aufbereitet zur Verfügung gestellt. Die gefilterten Messdaten werden in einer
Hashtable zwischengespeichert.
Nach dem Parsen sollen die eigentlichen Messdaten in die Persistenzschicht
gespeichert werden. Dazu werden die Objekte der Miele-Klassen DBConnection und
SQLIQuery verwendet. DBConnection ist für den Auf- und Abbau der Datenbank-
verbindung zuständig, während die Klasse SQLIQuery die SQL-Statements mit den
entsprechenden Operationen wie Select, Insert, Update oder Delete entgegennimmt
und ausführt. Des Weiteren stellt es die mit der Select-Anweisung angeforderten
Daten zur Verfügung.
4.3 Entwurf
47
Die TitrationControler–Anwendung soll ebenfalls von der Thread-Klasse erben und
als nebenläufige Instanz ausgeführt werden.
In den gesamten Anwendungen soll dabei stets das Prinzip gewahrt werden, dass
alle benötigen Daten, wie z.B. die Regeln/Bedingungen für den Parser oder die
Verbindungsdaten zum Com-Server, in der Informix-Datenbank hinterlegt sind und
nicht im Quellcode hart eingetragen werden.
Klasse: TitrationStarterBean
Die TitrationStarterBean stellt eine JavaBean (siehe folgenden Kapitel 5.2.2) dar, die
die Aufgabe hat, die Klasse TitrationControler als Objekt zu instanziieren und die
Anwendung zu starten. Des Weiteren soll die Bean den aktuellen Status der
laufenden Anwendung abfragen und an die entsprechenden JSP-Seiten bekannt
geben. Zusätzlich soll die Bean, bei Aufruf eines manuellen Abbruchs der
Messungen in den JSP-Seiten, ein Abbruchsignal an die TitrationControler-
Applikation weiterreichen. Das Abbruchsignal führt zu einem kontrollierten Schließen
des Sockets und der Datenbankverbindung sowie zum Beenden der Applikation
selbst. Das Setzen und Erfragen von Werten/Signalen erfolgt mittels der öffentlichen
Getter- und Setter-Methoden.
48
5 Implementierung
Neben der Analyse des bestehenden Prozesses und der Erstellung des Konzeptes
zur Umsetzung des neu entwickelten Titrationsprozesses innerhalb von ProLab ist
auch die Realisierung des gesamten Moduls Titration Aufgabe der Bachelorarbeit.
Die für die Integration des Moduls benötigten Masken und Funktionalitäten werden in
diesem Abschnitt erläutert.
5.1 Organisatorisches
5.1.1 Vorgehensmodell
Bei der Firma Miele im Bereich Labordienstleistungen ist kein spezielles
Vorgehensmodell zur Durchführung von Softwareprojekten vorgeschrieben, sodass
die einzelnen Projektteams selbst entscheiden können, wie sie vorgehen möchten.
Ich habe mich für ein iterativ inkrementelles Vorgehensmodell entschieden, da es mir
sehr gut aus der Vorlesung Software Engineering bekannt ist und es bestens
während der Realisierung dieses Projekts angewandt werden kann.
5.1.2 Eingesetzte Technologie und Werkzeuge
Die Webapplikation ProLab wird mit der JSP-Technologie entwickelt (vgl. Kap. 2.1.2).
Dies setzt voraus, dass das Modul Titration ebenfalls mit denselben Techniken und
Technologien realisiert wird. Als Entwicklungsumgebung wird Netbeans der Firma
Sun Microsystems genutzt. Netbeans bietet für die Entwicklung von JSP-Projekten
komfortable Möglichkeiten zur Programmierung und zum Debugging an. Um die
Projekte testen zu können, ist unter anderem der Tomcat-Application-Server
integriert, der auch im Produktivbetrieb eingesetzt wird.
Neben JSP wird stellenweise auch JavaScript eingesetzt. Zum Betrachten der Seiten
kommt während der Entwicklungsphase ein normaler Web-Browser, wie etwa Firefox
oder der Internet Explorer, zum Einsatz. Im Produktivbetrieb wird dieser Browser
durch eine bei Miele intern entwickelte Laufzeitumgebung auf Firefox-Basis ersetzt.
5.2 Allgemeine in ProLab verwendete Techniken
49
5.2 Allgemeine in ProLab verwendete Techniken
Das System ProLab, welches als webbasierte, modular aufgebaute Applikation
entwickelt wurde, umfasst einen recht großen Umfang. Deshalb wurden einige
Hilfsmittel geschaffen, die ein paralleles Entwickeln ermöglichen und den Komfort bei
der Anwendung (schnelle Antwortzeiten und sicheres, unabhängiges Arbeiten)
gewährleisten. Einige davon werden im Folgenden kurz vorgestellt.
5.2.1 Include-Dateien
Um leichter eine wiederholte Nutzung von einem bereits erstellten Code zu
ermöglichen, werden seit Projektstart einige Blöcke in ein include-Verzeichnis
ausgelagert. Diese Dateien werden mit dem Aufruf <%@ include
file="/includes/Dateiname.include"%> eingefügt. Ein Beispiel dafür ist die Datei
/web/includes/getStandardClassImports.include :
Listing 5.1 - Include-Beispiel
Anhand des Listing 5.1 ist zu erkennen, wie einfach die Möglichkeit gegeben ist,
Klassen, die in jeder einzelnen jsp-Datei eingebunden werden müssen, auszulagern
und durch eine einzelne include- Anweisung wieder einzubinden.
Die mit der include-Anweisung eingebunden Dateien werden beim Kompilieren in die
aufrufende Datei eingefügt und mit übersetzt.
<%-- misc. java classes --%>
<%@page import="java.util.*"%> <%@page import ="java.io.*"%>
<%-- SQLInterface --%>
<%@page import ="net.miele.de.gtg.kew.itms.sqlinterface.con.*"%>
<%@page import ="net.miele.de.gtg.kew.itms.sqlinterface.dbaccess.*"%>
<%@page import ="net.miele.de.gtg.kew.itms.sqlinterface.err.*"%>
<%-- some ProLab classes --%>
<%@page import ="net.miele.de.gtg.kew.itms.prolab.gui.CodeSnippets"%>
<%@page import ="net.miele.de.gtg.kew.itms.prolab.gui.datahandling.
DBColumnObject"%>
<%@page import ="net.miele.de.gtg.kew.itms.prolab.gui.navigation.
NavSection“ %>
5.2 Allgemeine in ProLab verwendete Techniken
50
5.2.2 JavaBeans in JSP-Seiten
Eine JavaBean ist eine Java-Klasse, die einem Komponentenmodell entspricht, um
automatisierten Zugriff auf ihre Eigenschaften und Operationen zu erlauben. Diese
werden z.B. als Container zur Datenübertragung verwendet. Alle JavaBeans
zeichnen sich durch folgende Eigenschaften aus:
Öffentlicher Standardkonstruktor,
Serialisierbarkeit,
Öffentliche Zugriffsmethoden.
Um eine Bean, z.B. die DatenTestBean.java, den entsprechenden JSP-Seiten zur
Verfügung zu stellen, wird der Aufruf <jsp:useBean id="TestBean" class="net.miele.de.
DatenTestBean.java" scope="session" /> in die Seiten eingebettet.
Da das HTTP-Protokoll zustandslos ist und Informationen über den Client zwischen
dem Aufruf verschiedener Seiten verloren gehen, wurden für die Verfügbarkeit der
Beans in den JSPs vier Gültigkeitsbereiche (scopes) festgelegt. Tabelle 5.1 zeigt die
Gültigkeitsbereiche auf und erläutert die Funktionen.
Name Bedeutung
application Mit dem Starten der Applikation (bspw. durch Hochfahren des Tomcat) steht dieser Gültigkeitsbereich bis zum Beenden der Applikation zur Verfügung.
session Eine Session umfasst eine Nutzersitzung und umfasst mehrere Anfragen. So kann z.B. der Status eines Benutzers während der Nutzung gespeichert werden
request Dieser Gültigkeitsbereich umfasst genau eine Anfrage eines Nutzers. Aufgrund eines möglichen Forwardings der Anfrage an weitere JSPs kann ein Request sich über mehrere JSPs erstrecken.
page Dieser Gültigkeitsbereich ist nur innerhalb genau einer JSP gültig. Bei einem Forwarding gehen Attribute dieses Gültigkeitsbereichs verloren.
Tabelle 5.1 - Gültigkeitsbereiche einer JavaBean in JSPs
Mit Hilfe der Tags <jsp:getProperty> und <jsp:setProperty> kann auf ein Attribut der
Bean zugegriffen bzw. ein Attribut gesetzt werden. [15]
5.2 Allgemeine in ProLab verwendete Techniken
51
5.2.3 Datenbankverbindung
Um Datenbankverbindungen in ProLab effektiv nutzen zu können, gibt es die Java-
Bean net.miele.de.gtg.kew.itms.sqlinterface.dbaccess.Beans.DBConPoolBean, welche
einen Pool von Connect-Objekten anbietet. Mit dieser Bean ist es einer JSP-Seite
möglich, eine Verbindung zur Datenbank anzufordern und diese zu verwenden.
Dabei übernimmt die Bean das Verbindungs-Management.
Aufgrund der langen Anmeldevorgänge an der Datenbank werden Verbindungen
nach der Benutzung nicht sofort geschlossen, sondern für eine vorgegebene Zeit
gehalten und als Status „nicht in Benutzung“ markiert. Sollte in diesem festgelegten
Zeitfenster erneut eine Verbindung angefordert werden, so übergibt die Bean
zunächst ein Objekt mit einer bereits bestehenden, aufgebauten Verbindung an die
entsprechende JSP-Seite. Erst wenn keine freien Objekte mit aufgebauter
Verbindung mehr vorhanden sind, wird ein Neues angelegt, für das der
Anmeldevorgang ausgeführt werden muss. Die maximale Anzahl der Verbindungs-
objekte, sowie die maximale Zeitdauer, nach der bei Inaktivität die Verbindungen
gehalten werden, können über eine Administrationsseite innerhalb ProLabs
konfiguriert werden
5.2.4 Zugangskontrolle
Das ProLab-System ist mit zahlreichen Sicherheitsmechanismen ausgestattet. Bevor
ein Benutzer das System verwenden kann, ist eine Authentifizierung des Users nötig.
Dies erfolgt über einen LDAP-Server, der mit dem ProLab verbunden ist.
Dem Benutzer sind über Rollen verschiedene Access-Objects (ACOs) zugeordnet.
Diese ACOs werden beim Aufruf einer Seite, mittels der Include-Datei
PageIdent.include, überprüft. Die Include-Datei liegt dabei in jedem Verzeichnis vor
und wird beim Aufruf einer Seite eingelesen. In der Datei steht der Name eines
ACOs. Ist das zu dem Namen gehörige ACO dem Benutzer über die
Benutzerverwaltung ProLabs zugeordnet, so wird die Seite erfolgreich aufgebaut.
Dem Benutzer wird jedoch der Zugriff verweigert und die gewünschte Seite nicht
aufgebaut, wenn dieser den entsprechenden Eintrag der ACO in der
Benutzerverwaltung nicht vorliegen hat. Die Überprüfung erfolgt durch die Java-Bean
net.miele.de.gtg.kew.itms.apps.beans.CheckAccessBean.
5.2 Allgemeine in ProLab verwendete Techniken
52
5.2.5 Label
Die Software ProLab soll zum einen nicht nur modular, webbasiert entwickelt
werden, sondern auch die Aspekte der Benutzerfreundlichkeit beachten. Dazu zählt
auch das Verwenden der Applikation in mehreren Sprachen. Derzeit sind die
Sprachen deutsch und englisch vorgesehen. Es können jedoch auch Weitere
problemlos nachgerüstet werden.
Dabei werden die in den Webseiten dargestellten Texte nicht direkt im Quellcode der
Anwendung, sondern in der Datenbank hinterlegt. Der Quellcode selber verwendet
dabei die sogenannten Labels, die als Platzhalter für die entsprechenden Texte
agieren. Über die Label-Bean net.miele.de.gtg.kew.itms.prolab.gui.beans.LabelBean
und dem Aufruf AppLabel.getLabelValue(“TestLabel“) wird das Label durch den
gewünschten Text ersetzt und auf der Seite in der vorgegebenen Sprache angezeigt.
Des Weiteren hat das Label-Verfahren, neben der Mehrsprachigkeit, den
zusätzlichen Vorteil, dass Änderungen am Quellcode nicht vorgenommen werden
müssen, falls sich die Bezeichnungen ändern. Somit kann umgehend auf Benutzer-
Anfragen reagiert werden.
Das Erstellen und Pflegen der Labels erfolgt in einem administrativen Bereich von
ProLab.
5.3 Modul Titration
53
5.3 Modul Titration
In diesem Abschnitt der Arbeit werden die relevanten Applikationen und Masken des
Moduls Titration detailliert erläutert und mit kurzen Quellcode-Ausschnitten veran-
schaulicht.
Wie bereits in Kapitel 4.3 Entwurf genannt, besteht das ProLab-Modul Titration aus
zwei wesentlichen Bereichen: Der Messdatenerfassung (s. Kapitel 4.3.3) und der
Titrationsverwaltung (s. Kapitel 4.3.2). Die Implementierung der Messdatenerfassung
erfolgt ausschließlich durch die Programmiersprache Java, wohingegen die GUI bzw.
die Masken der Titrationsverwaltung als JSP-Technologie sowohl die
Programmiersprache Java als auch die Auszeichnungssprache HTML verwenden.
5.3.1 Messdatenerfassung
SocketReader
Der SocketReader ist eine in Java entwickelte Klasse, die für die Netzwerkverbindung
und den Datenempfang zwischen dem Com-Server und dem Titrations-Modul
verwendet wird. Um den SocketReader parallel bzw. nebenläufig im Tomcat-
Application-Server laufen lassen zu können, erbt dieser von der Klasse Thread und
führt die Aufgaben als eigene Thread-Instanz aus. Dabei müssen die Methoden, die
nebenläufig sein sollen, in der geerbten und überschriebenen Thread-Methode run()
aufgerufen werden. Die run()-Methode ist der zentrale Punkt des SocketReaders, in
der die meisten Methoden ausgeführt werden.
Ein weiterer wichtiger Punkt, ohne den eine Netzwerkkommunikation gar nicht erst
zustande kommen würde, ist die Klasse Socket. Diese dient als plattformunab-
hängige, standardisierte Schnittstelle zwischen der Netzwerkimplementierung des
Betriebssystems und der eigentlichen Applikation SocketReader. Dazu verwendet die
Applikation eine Socket-Instanz, mit deren Hilfe eine Netzwerkverbindung und der
Empfang der Messdaten ermöglicht werden.
Das Listing 5.2 zeigt einen Ausschnitt der Aufrufe von Methoden in der run()-
Methode sowie die Deklarierung der Objekte der drei benötigten Klassen Socket,
InputStreamReader und BufferedReader.
5.3 Modul Titration
54
Listing 5.2 - Verwendung der Run()-Methode
Der InputStreamReader wird benötigt, um die vom Socket-Objekt empfangenen
Daten als Datenstrom entgegenzunehmen und einen sequentiellen Zugriff auf die
Daten zu gewährleisten. Dabei wird der vom Socket zur Verfügung gestellte byte-
orientierte Datenstrom in einen zeichen-orientierten Datenstrom umgewandelt. Da
der InputStreamReader die Daten nur zeichenweise oder als festgelegte Feldgrößen
ausgeben kann, wird zusätzlich der BufferedReader verwendet. Dieser erlaubt mit
Hilfe der Methode readline() das Puffern und zeilenweise Auslesen der Daten. Das
Objekt des InputStreamReaders wird dabei dem Konstruktor des BufferedReader-
Objekts übergeben. In Listing 5.3 sind die Instanziierung der Klassen und der Aufbau
der Socket-Verbindung durch Angabe von Host und Port zu erkennen.
public class SocketReader extends Thread{
...
private Socket socket;
private InputStreamReader isr;
private BufferedReader inData;
@Override
public void run(){
try{
...
getSocketConnnection();
...
while(stopSocket == false){
//getData from Socket
...
}
...
} catch(...){
...
} finally {
closeSocketConnection();
}
}
...
}
5.3 Modul Titration
55
Listing 5.3 - Instanziierung der benötigen Klassen und Aufbau der Socketverbindung
Das eigentliche, zeilenweise Auslesen der Daten geschieht in einer while-Schleife
innerhalb der run-Methode. Da die Messdaten in unregelmäßigen Abständen und mit
Wartezeiten von bis zu 4 Minuten pro Messung gesendet werden, ist ein dauerhaftes
Lauschen im Netzwerk nötig. Dabei wird die Socket-Verbindung solange gehalten,
bis eine Abbruchbedingung die while-Schleife beendet und die Verbindung schließt.
Eine der Abbruchbedingungen ist die zuvor definierte Variable maxTimeToRun,
welche eine maximale Zeit für die Applikation festlegt. Die zweite Bedingung reagiert
auf ein von außen erhaltenes Abbruchsignal. Das Abbruchsignal wird gesendet,
wenn alle Messungen abgeschlossen sind oder der Labormitarbeiter einen
manuellen Abbruch des Messvorgangs ausführt. Aber auch bei unerwarteten Fehlern
wird ein Abbruchsignal an den SocketReader gesendet, damit dieser die Verbindung
sauber schließt und die Anwendung beendet.
Die in der while-Schleife zeilenweise ausgelesenen Daten werden vom
BufferedReader an ein Vector-Objekt übergeben. Das Vector-Objekt stellt eine Liste
dar, die die zeichen-orientierten Zeilen (String-Zeilen) aufnimmt und als Zwischen-
speicher verwaltet. Der Vektor wird anschließend nebenläufig von der
TitrationControler-Klasse ausgelesen und die darin enthaltenen Daten werden
weiterverarbeitet. Das folgende Listing 5.4 zeigt die while-Schleife mit den Abbruch-
bedingungen und der Übergabe der Daten an den Vektor.
...
private void getSocketConnection() throws Exception{
socket = new Socket(host, Integer.parseInt(port));
isr = new InputStreamReader(socket.getInputStream());
inData = new BufferedReader(isr);
}
...
5.3 Modul Titration
56
Listing 5.4 - Abbruchbedingungen und Datenzwischenspeicherung
Eine weitere relevante Methode stellt die öffentliche Setter-Methode
setThreadInterrupt() dar. Diese ist von außerhalb aufrufbar und dient zum Setzen
des Abbruch- bzw. Unterbrechungssignals. Sie ist deshalb so relevant, weil das
Signal in der while-Schleife als zweite Abbruchbedingung verwendet wird und das
Beenden und Schließen der Verbindung erst ermöglicht. In Listing 5.5 wird der Aufruf
der Methode dargestellt.
Listing 5.5 - Interrupt-Methode
...
public Vector<String> inDataLine;
private String line;
...
@Override
public void run(){
try{
...
getSocketConnnection();
...
while(stopSocket == false){
// checks if time is over
if(currentTime >= stopTime){
stopSocket = true;
System.out.println("The Sockettime is over.");
}
// checks if an Interrupt-Signal was send
if(this.isInterrupted() == true){
stopSocket = true;
System.out.println("An Interrupt-Signal was send.");
}
...
line = inData.readLine();
if((line != null) && line.trim().length() > 0){
inDataLine.add(line);
line = "";
}
}
} catch(...){
...
} finally {
closeSocketConnection();
}
}
...
...
public void setThreadInterrupt(){
this.interrupt();
}
...
5.3 Modul Titration
57
Die SocketReader-Applikation stellt zwei Konstruktoren zur Verfügung. Dem ersten
Konstruktor müssen bei Instanziierung des Objekts die Parameter Host und Port
übergeben werden. Der zweite Konstruktor bietet die Alternative, die entsprechend
benötigen Daten aus einer Konfigurationsdatei auszulesen. Dazu wird dem
Konstruktor der Speicherort der Config-Datei als Parameter mitgeteilt. Listing 5.6
stellt die zwei Konstruktoren dar.
Listing 5.6 - Konstruktoren der Klasse TitrationControler
Mittels der Klasse ConfigReader aus dem Miele Package net.miele.de.java.tools.io
werden die aus der Config-Datei benötigten Daten ausgelesen und dem
SocketReader in einem Hashtable<String,String>-Objekt bereitgestellt. Das
Entgegennehmen der Config-Daten aus der Hashtable erfolgt durch die
readConfigData(…)-Methode (siehe Listing 5.7).
Listing 5.7 - Konfigurationsmethode readConfigData()
...
public Socket Reader(String host, String port){
this.host = host;
this.port = port;
}
public SocketReader(String[] args){
this.argStringArray = args;
this.readConfStatus = true;
}
...
private Hashtable<String,String> conParms = new Hashtable
<String,String>();
...
private boolean readConfigData(String[] args) throws Exception{
confReader = new ConfigReader();
...
// first parameter is config file name. Rest should be redefinitions
// of parameters like conectHost or conncetPort
confReader.createConfiguration(this.conParms,
confReader.getConfigString(args));
...
this.host = this.conParms.get("connectHost");
this.port = this.conParms.get("connectPort");
...
maxTimeToRunString = this.conParms.get("maxTimeToRun");
...
return true;
}
...
5.3 Modul Titration
58
TitrationControler
Der TitrationControler ist eine ebenfalls in Java entwickelte Applikation. Diese
Klasse ist für das korrekte Speichern der Messdaten in die Informix-Datenbank
zuständig. Dazu werden die vom SocketReader bereitgestellten Daten von der
Applikation entgegengenommen, weiterverarbeitet und zum Schluss in die
Datenbank gespeichert. Das Weiterverarbeiten erledigt der Parser. Listing 5.8 zeigt
den internen Aufbau der Klasse mit den wichtigsten Methoden.
Listing 5.8 - Interner Aufbau des TitrationControlers
Tabelle 4.1 weist die für die TitrationControler Anwendung benötigten Datenbank-
tabellen auf.
Tabellenname Funktion
zzz_sys_app_config Dient als Konfigurationstabelle in der die Konfigurationsdaten wie z.B. Host oder Port eingetragen sind.
zzz_sys_parser_values Wird für den Parser benötigt. In dieser Tabelle stehen die Regeln bzw. Bedingungen drin, nach denen das Parsen ausgeführt wird.
a04_dat_test_titration Diese Tabelle speichert die Messdaten, die für das Modul Titration benötigt werden.
Tabelle 5.2 - Übersicht der Datenbanktabellen
public class TitrationControler extends Thread {
...
run(){
...
readConfigData(){
...
setMaxTimeToRun(…);
}
...
updateTransactionNumber();
...
getDatasets(){
init();
connectClient(…);
while(…){
getNextDataset(…){
...
saveData(…);
}
}
}
}
}
5.3 Modul Titration
59
Zunächst einmal erfolgt eine Vorbereitung des TitrationControlers auf die eigentliche
Arbeit. Dazu werden die benötigten Konfigurationsdaten mit Hilfe der
readConfigData()- Methode aus der Datenbank ausgelesen. Zu den Konfigurations-
daten zählen die Verbindungsdaten zum Com-Server (connectHost, connectPort)
sowie die maximal vorgegebene Laufzeit (maxTimeToRun). Mit der Hilfsmethode
setMaxTimeToRun(…) wird der String in eine Zahl umgewandelt, um diese für den
Socket-Aufbau lesbar zu machen. Zusätzlich wird die updateTransactionNumber() –
Methode verwendet, die die letzte Transaktionsnummer aus der Datenbank ermittelt
und für den durchzuführenden Messvorgang eine neue Transaktionsnummer (letzte
Nummer + 1) generiert. Der etwas detaillierte Aufbau der readConfigData() –
Methode wird in Listing 5.9 dargestellt.
Listing 5.9 - readConfigData()-Methode zur Ermittlung der Konfigurationsdaten
Nachdem die Konfigurationsdaten ermittelt wurden, erfolgen die Vorbereitung und
der Aufbau des Parsers sowie die Verbindung zum Com-Server in der getDatasets()-
Methode. Die getDatasets()- Methode führt dabei die Aufgaben, gekapselt in weiteren
internen Methoden (siehe Listing 5.8), aus.
Die erste interne Methode ist die init()-Methode. Diese ist für die Initialisierung des
Parsers zuständig, d.h. es werden die Regeln bzw. Bedingungswerte für das Parsen
aus der Informix-Datenbank ausgelesen und in eine Hashtable dataFields
eingetragen. Wie bereits genannt, wurden die Bedingungswerte zuvor in der Analyse
festgelegt.
private boolean readConfigData(){
try {
setDbConInformix(new DBConnectionInformix(dbServer, dbHost,
dbPort, dbName, dbUser,dbPasswd));
...
sqlDataObject.addStatement("select_config_Data", "select
valuename, value from informix.zzz_sys_app_config WHERE
valuename LIKE 'Titration%'");
...
sqlDataObject.execute("select_config_Data");
...
maxTimeToRun = sqlDataObject.getResultValue("select_config_Data",
2, x).toString().trim();
...
setMaxTimeToRun(maxTimeToRun);
} catch (Exception ex) {
...
return false;
}
return true;
}
5.3 Modul Titration
60
Dazu wurde der Report, der übers Netzwerk gesendet wurde, analysiert und die
benötigen Daten in der entsprechenden Ausgabezeile ermittelt. Die Tabelle 5.3 zeigt
einen Ausschnitt der Regeln, die für das Parsen relevant sind.
Key Value
datasetstart $S PC/LIMS V1
datasetend $S 07 T+ Report
$S Result 1C.R1_Col_0 res1name
$S Result 1C.R1_Col_1 res1value
$S Result 1C.R1_Col_2 res1unit
$S Props V2_Col_0 method
$S System_V1_Col_1 relativeid
$S System_V1_Col_2 absoluteid
… … Tabelle 5.3 - Parser-Tabelle
Die ersten zwei Einträge (datasetstart und datasetend) in der Tabelle sind für das
Erkennen eines kompletten Datensatzes innerhalb des Datenstroms zuständig. Die
weiteren Einträge dienen zum Ermitteln des gewünschten Messwerts (Key) und des
Eintragens in die entsprechende Spalte (Value) der Datenbank.
Das Listing 5.10 zeigt den Aufbau der init()-Methode.
Listing 5.10 - Aufbau der init()-Methode
...
private boolean init(){
try {
// define an informix sqlquery object
SQLIQuery sqlInitObject = new SQLIQuery(dbConInformix);
sqlInitObject.addStatement(parserDataName, selectParserData);
sqlInitObject.execute(this.parserDataName);
for(row=1; row <= sqlInitObject.getNumOfResultRows(parserDataName);
row++){
key = sqlInitObject.getResultValue(parserDataName, "key", row)
.toString().trim();
value = sqlInitObject.getResultValue(parserDataName, "value", row)
.toString().trim();
dataFields.put(key, value);
}
} catch(Exception ex){
...
return false;
}
return true;
}
...
5.3 Modul Titration
61
Zunächst einmal wird in der init()-Methode ein SQLIQuery-Objekt (sqlInitObject)
instanziiert, welches für die Anfragen an die Datenbank zuständig ist. Dem Objekt
wird mit der addStatement(…)-Methode eine Select-Anweisung zugewiesen und mit
sqlInitObject.execute(…) ausgeführt. Danach werden die aus der Parser-Tabelle
selektierten Werte key und value in die Hashtable dataFields mit der put(key,value)-
Methode eingetragen.
Nach der init()- wird als nächstes die connectClient()- Methode ausgeführt. Diese ist
zuständig für das Instanziieren eines Socket-Objekts der SocketReader-Klasse sowie
das Starten dieser Instanz. Zusätzlich wird dem Objekt die maximale Laufzeit
mitgeteilt, die zuvor aus der Konfigurationstabelle ermittelt wurde. Des Weiteren prüft
die Methode, ob ein Verbindungsaufbau zustande kam. In Listing 5.11 wird die
Methode zur Socket-Verbindung dargestellt.
Listing 5.11 - connectClient()-Methode für die Socketverbindung
Nachdem die Verbindung mit der connectClient()-Methode aufgebaut und geprüft
wurde, wird das Auslesen bzw. das Entgegennehmen der Daten vom SocketReader-
Objekt innerhalb der getDatasets()-Methode in einer while()-Schleife durchgeführt.
Dabei wird die Schleife solange ausgeführt, bis die maximale Laufzeit erreicht ist
oder alle Messdaten in der Datenbank eingepflegt wurden und von außen ein
Abbruchsignal den Durchlauf beendet.
Listing 5.12 zeigt den Ablauf der Schleife innerhalb der getDatasets()-Methode.
private boolean connectClient(String host, String port){
try{
socketReader = new SocketReader(host, port);
socketReader.setMaxTimeToRun(timeToRun);
socketReader.start();
//Wait 1sec till the socket is connected
TitrationControlBean.sleep(1000);
if(socketReader.getIsConnected() != true){
return false;
}
} catch( Exception ex ){
...
return false;
}
return true;
}
5.3 Modul Titration
62
Listing 5.12 - while-Schleife in der getDatasets()-Methode
In der Schleife werden zunächst die empfangen Daten, die vom SocketReader als
Vector-Objekt bereitgestellt werden, entgegengenommen und an die interne
Methode getNextDataset() weiter gereicht. Diese benötigt als Übergabe Parameter
das Vector-Objekt inDataLineBuffer sowie die in der Hashtable dataFields
eingetragen Werte zu den Keys datasetstart und datasetend. Die Werte wurden zuvor
aus der Parser-Tabelle in die Hashtable eingetragen (siehe Listing 5.10 init()-
Methode).
...
datasetCount = 1;
while(!socketReader.getIsClosed()&&((datasetCount <= noOfDatasetsToRead)
&& (currentTime < stopTime))){
...
inDataLineBuffer = socketReader.inDataLine;
if(getNextDataset(inDataLineBuffer, dataFields.get("datasetstart"),
dataFields.get("datasetend"))){
datasetCount++;
}
}
...
5.3 Modul Titration
63
Nach den ganzen Vorbereitungen, wie die Initialisierung und der Verbindungsaufbau,
erfolgt das eigentliche Parsen und Speichern der Messdaten in der Methode
getNextDataset(…).
Um den Vorgang des Parsen zu verdeutlichen, soll das Listing 5.13 noch einmal ein
Beispiel eines Report-Auszuges zeigen. In dem Auszug ist der Datensatzstart (grün)
und das Datensatzende (gelb), wie in der Parser-Tabelle festgelegt, zu erkennen.
Innerhalb eines kompletten Datensatzes einer Messung werden die Daten
zeilenweise im Report dargestellt. Dabei werden die Messdaten in einer
geschachtelten Form ausgegeben. Die Form sieht dabei folgendermaßen aus:
$S „Messdatenbezeichnung“
Messdatum1 Messdatum2 Messdatum3 …
$E
Damit der Parser die richtigen Daten einer Messung auffindet, sucht dieser mit Hilfe
der Parser-Regeln nach der Messdatenbezeichnung und erhält die Messdaten in der
darunterliegenden Zeile. Die Messdaten werden dabei mit dem Tabulator-
Trennzeichen auseinander gehalten.
Listing 5.13 – Reportauszug mit Beispiel-Messdaten
$S PC/LIMS V1
...
$S Result 1C.R1 V1
Probe 5.505 mL 0
$E
$S Result 1C.R2 V1
Ergebnis 0.975 mL 0
$E
$S Result 1C.R3 V1
pH-Init 7.73 0
$E
...
$S 07 T+ Report
on ok ok
$E
$E
5.3 Modul Titration
64
Das Listing 5.14 zeigt den Ablauf der getNextDataset(…) –Methode und im Anschluss
daran erfolgt eine Erläuterung dieser Methode.
Listing 5.14 - Aufbau der getNextDataset()-Methode
...
private boolean getNextDataset(Vector<String> lineBuffer,
String dataStartFilter, String dataEndFilter){
try {
Hashtable<String,String> newData = new Hashtable<String,String>();
Integer lineBufferSize = lineBuffer.size();
Integer dataStart=-1;
Integer dataEnd=-1;
if(lineBufferSize == 0){
return false;
}
// look for end of dataset
for(Integer line=0; line < lineBufferSize;line++){
if(lineBuffer.get(line).toString().matches(dataEndFilter)){
dataEnd = line;
break;
}
}
// look for start of dataset
for(Integer line=0; line < lineBufferSize; line++){
if(lineBuffer.get(line).toString().matches(dataStartFilter)){
dataStart = line;
break;
}
}
...
// put all name-value pairs into Hashtable
for(Integer line = dataStart; line < dataEnd; line++){
//if this line is starting with "$S" and next line is starting
//without "$", we put this line and next line into the hashtable
String zeile=lineBuffer.get(line).toString();
String zeile_n=lineBuffer.get(line+1).toString();
if(!zeile.matches("^\\$S.*")){
continue;
}
if(!zeile_n.matches("^\\$.*")){
newData.put(zeile, zeile_n);
}
}
saveData(newData);
} catch (Exception ex){
...
}
return true;
}
...
5.3 Modul Titration
65
Als Erstes wird geprüft, ob die im Vector-Objekt enthaltenen Daten einen
Datensatzstart (dataStartFilter) und ein Datensatzende (dataEndFilter) einer
Messung enthalten. Dies ist wichtig, damit ein eindeutiger Datensatz einer Messung
identifiziert werden kann. Danach werden die in diesem Datensatz enthalten Zeilen
ausgelesen und in die Hashtable newData gespeichert. Dabei wird zunächst geprüft,
ob die Zeilen der geschachtelten Form (1.Zeile Messdatenbezeichnung, 2.Zeile
Messdaten) entsprechen. Ist dies der Fall, so wird die erste Zeile (Messdaten-
bezeichnung) als key und die zweite Zeile als value in der Hashtable hinterlegt. Somit
enthält newData alle Zeilen des einen gefunden Datensatzes. Die Tabelle 5.4 zeigt
die Hashtable newData mit Beispieleinträgen der Datenzeilen. Dabei sind die
Messdaten im value-Bereich mit dem Tabulatortrennzeichen separiert eingetragen.
Key value
$S Result 1C.R1 V1 Probe 5.505 mL 0
$S Result 1C.R2 V1 Ergebnis 0.975 mL 0
$S Result 1C.R3 V1 pH-Init 7.73 0 Tabelle 5.4 - Beispieleinträge in der newData-Hashtable
Damit die in der Hashtable enthalten Messdaten aus den Datenzeilen herausgefiltert
und in die Datenbank gespeichert werden können, wird die saveData(…)-Methode
verwendet. Als Übergabeparameter erhält die Methode die Hashtable newData.
Da die Methode saveData() eine sehr große Anzahl an Quellcode aufweist und die
komplette Darstellung in einem Listing unübersichtlich wirkt bzw. zur Verwirrung
führt, werden nur die wichtigsten Funktion dargestellt und erläutert.
Das Speichern der Daten erfolgt in einer while-Schleife, bei der alle Datenzeilen der
Hashtable überprüft und abgearbeitet werden. Um die Messdaten in die Informix –
Datenbank einzutragen, ist vorher ein Parsing-Prozess nötig, der die benötigten
Messdaten aus den übrigen Daten herausfiltert und ein SQL-Statement zum
Speichern der Daten generiert.
5.3 Modul Titration
66
Zunächst einmal wird eine Datenzeile aus der Hashtable newData ausgelesen und
die mit Tabulatortrennzeichen separierten Messdaten mit Hilfe der split(“\t“)-
Methode in ein String-Array hinterlegt. Danach wird das Array in einer for-Schleife
durchlaufen. In dieser Schleife erfolgt die Überprüfung der Schlüsselwerte (key)
beider Hashtables newData und dataFields.
Um den Vergleich durchführen zu können, muss der Schlüsselwert aus newData
entsprechend angepasst werden. Dazu wird die Variable keySearch verwendet, die
eine Kopie des Schlüsselwerts enthält. Zusätzlich zum Wert wird der String „_Col_“
und die Indexzahl der for-Schleife angehängt. Somit wird exemplarisch aus dem
Wert „$S Result 1C.R1 V1“ der neue Wert „$S Result 1C.R1 V1_Col_1“.
Nun ist der neu generierte Wert mit den Schlüsselwerten aus dataFields vergleichbar.
Mit dem Aufruf dataFields.containsKey(keySearch) wird geprüft, ob der neu generierte
Schlüsselwert in der dataFields-Hashtable enthalten ist. Ist dies nicht der Fall, so wird
in der for-Schleife fortgefahren. Besteht eine Übereinstimmung, so wird der value-
Wert zum entsprechenden key-Wert aus dataFields entnommen und in die String-
Variable colname gespeichert. Der dazugehörige Messwert wird aus dem String-
Array ausgelesen und in colvalue hinterlegt.
Um einen Insert- oder Update-Befehl (Statement) in der Datenbank ausführen zu
können, muss das Statement vorher zusammengebaut werden. Dazu werden die
beiden Werte colname und colvalue an die entsprechenden StringBuffer-Variablen
sqlcolnames und sqlcolvalues angehängt.
Den beschriebenen Vorgang soll das Listing 5.15 verdeutlichen.
Anmerkung: Die gesamte Methode saveData() wird zur besseren Lesbarkeit und
Übersicht in drei Bereiche (Listing 5.15 bis Listing 5.17) eingeteilt und erläutert.
5.3 Modul Titration
67
Listing 5.15 – Parsing-Vorgang in der saveData()-Methode
Nachdem die kompletten Datenzeilen durchlaufen und die Werte in die
entsprechenden Variablen sqlcolnames und sqlcolvalues eingetragen wurden, erfolgt
das Zusammenbauen der SQL-Statements und das anschließende Speichern der
Messdaten in die Datenbank. Als erstes wird überprüft, ob bereits ein Datensatz mit
der relativen und der absoluten ID in der Datenbanktabelle a04_dat_test_titration
vorhanden ist. Ist dies nicht der Fall, so wird der Datensatz mit dem Insert-Statement
eingetragen. Besteht bereits ein Datensatz, so wird dieser Datensatz mit dem
Update-Statement aktualisiert. Der Zusammenbau eines SQL-Statements erfolgt mit
den Methoden addStatement(…) und appendSQLCode(…) und das Ausführen des
Statements mit execute(…).
...
private boolean saveData(Hashtable newData){
try{
if(!dbConInformix.getConnection()){
return false;
}
...
Enumeration enumNewData = newData.keys();
while(enumNewData.hasMoreElements()){
// Key of current Object
String newDataKey = enumNewData.nextElement().toString();
String newDataValue = newData.get(newDataKey).toString();
String[] newDataValueArray = newDataValue.split("\t");
Integer dataMaxIndex = newDataValueArray.length;
StringBuffer keySearch = new StringBuffer();
// work through values
for(Integer index = 0; index < dataMaxIndex;index++){
keySearch.append(newDataKey);
keySearch.append("_Col_");
keySearch.append(index.toString());
if(dataFields.containsKey(keySearch.toString())){
String colname = dataFields.get(keySearch.toString());
String colvalue = newDataValueArray[index];
...
sqlcolnames.append(colname);
sqlcolvalues.append(colvalue);
...
}
} //Ende-FOR-Schleife
} // Ende-WhILE-Schleife
...
5.3 Modul Titration
68
Listing 5.16 - Zusammenbau des Select-Statements
Ist das Select-Statement zusammengebaut und ausgeführt worden, so wird als
nächstes mit der Methode getNumOfResultRows(“select“) die Anzahl der selektierten
Datensätze geprüft. Entsprechend des Ergebnisses 0 oder 1 wird entweder ein
Insert- oder ein Update- Befehl benötigt. Dabei wird zunächst das Insert- bzw. das
Udpate-Statement zusammengebaut und mit der execute-Methode ausgeführt.
Das Listing 5.17 zeigt die Ausführung beider Statements. Der Aufbau der Statements
wird im Listing jedoch nicht aufgeführt, da der Ablauf sich analog zum Aufbau des
Select-Statements aus Listing 5.16 verhält.
...
sqlDataObject.addStatement("select", "select * from
a04_dat_test_titration where ");
sqlDataObject.appendSQLCode("select", whereSpaltenName1 +"="+
whereSpaltenValue1);
sqlDataObject.appendSQLCode("select"," and "+ whereSpaltenName2 +
"=" + whereSpaltenValue2);
sqlDataObject.appendSQLCode("select"," and creation is null");
if(!sqlDataObject.execute("select")){
return false;
}
...
5.3 Modul Titration
69
Listing 5.17 - Ausführung des Insert- und Update-Befehls
TitrationStarterBean
Die TitrationStarterBean ist eine sehr kompakte Klasse mit nur wenigen Methoden.
Diese sind öffentliche Getter- und Setter-Methoden, welche als Informations-
austausch zwischen ProLab und dem TitrationControler dienen sowie die
Abbruchsignale durchreichen. Listing 5.18 zeigt den Ablauf der TitrationStarterBean.
Die Methode getStarten() ist für das Instanziieren und Starten der TitrationControler-
Klasse zuständig. Dabei wird die run()-Methode im Konstruktor des
TitrationControler-Objekts aufgerufen und somit gestartet.
Damit das ProLab-System den aktuellen Arbeitsstatus des Objekts kennt, wird die
getWorkStatus()-Methode verwendet. Diese gibt eines der 4 Zustände aus: 0 für
„TitrationControler noch nicht gestartet“, 1 für „TitrationControler wird zur Zeit
ausgeführt“, 2 für „TitrationControler hat die Arbeit erfolgreich ausgeführt“ und 3 für
„TitrationControler ist auf ein Fehler gestoßen und wurde beendet“.
...
//if result is 0, do an insert
if(sqlDataObject.getNumOfResultRows("select") == 0){
... // Zusammenbau des insert-statements
if(!sqlDataObject.execute("insert")){
return false;
}
return true;
}
//if result is 1, do an update
if(sqlDataObject.getNumOfResultRows("select") == 0){
... // Zusammenbau des update-statements
if(!sqlDataObject.execute("update")){
return false;
}
return true;
} else {
return false;
}
} catch(Exception ex){
return false;
}
return true;
}
...
5.3 Modul Titration
70
Die Methode getIsSocketClosed() dient zum Erfragen des Socket-Status im ProLab-
System. Diese gibt den boolean-Wert true zurück, wenn der Socket vom
SocketReader geschlossen wurde. Andernfalls ist der Wert false.
Um ein Abbruchsignal vom ProLab-System an den TitrationControler und den
SocketReader zu senden, wird die setDisconnectClient()-Methode verwendet. Dabei
führt das Abbruchsignal zu einem kontrollierten Beenden der zwei Klassen.
Listing 5.18 - Aufbau der TitrationControler Bean
public class TitrationStarterBean {
public TitrationControler titration;
public int getStarten(){
titration = new TitrationControler();
return 1;
}
public int getWorkStatus(){
if(titration != null){
return titration.getWorkStatus();
}
return 0;
}
public boolean getIsSocketClosed(){
if(titration != null){
return titration.getIsSocketClosed();
}
return true;
}
public void setDisconnectClient(){
if(titration != null){
titration.disconnectClient();
}
}
...
5.3 Modul Titration
71
5.3.2 Titrationsverwaltung
GUI des Moduls Titration
Das ProLab-System ist eine webbasierte Anwendung zur Prüfungsverwaltung. Die
grafische Benutzeroberfläche basiert auf Seiten, den sogenannten Masken, die mit
der JSP-Technologie realisiert werden. Für das Modul Titration werden ebenfalls
Masken benötigt, die den Titrationsprozess als Workflow abbilden. Dabei gliedern
sich die Masken in 3 Bereiche:
Synchronisationsvorgang,
Messvorgang,
Messdatenübersicht.
Für fast alle Masken werden nahezu die gleichen JSP-Techniken in einer
abgeänderten Form angewendet. Deshalb soll in diesem Abschnitt eine allgemeine
Zusammenfassung der relevanten Techniken bzw. des Quellcodes aufgeführt
werden. Im Anschluss werden die Masken und deren Funktion vorgestellt. Es wird
jedoch kein detaillierter Quellcode zu den einzelnen Masken dargestellt, da dies den
Rahmen der Arbeit stark ausweiten würde. Folgende Techniken werden dabei kurz
erläutert: Sessions, Hidden Fields, Forwarding und Datenverwaltung in JSPs.
Sessions
Eine der Grundvoraussetzungen des ProLab-Systems ist die eindeutige Identi-
fizierung des Benutzers über mehrere Masken hinweg innerhalb einer Sitzung.
Um zusammengehörige Anfragen und Antworten eines Benutzer über mehrere
Masken erkennen und zuordnen zu können, bieten die meisten Webserver, wie auch
der Tomcat-Application-Server, die Session-Technik an. Eine Session ist eine
Sitzung, die über die Session-ID (eindeutige Identifikationsnummer der Sitzung) den
Benutzer authentifiziert. Dabei soll innerhalb des ProLab-Systems die Session-
Technik sowohl mit eingeschalteten Browser-Cookies als auch ohne funktionieren.
Bei Verwendung von Cookies erfolgt eine Übertragung der Session-ID an den Server
über den Header des HTTP-Protokolls. Werden diese nicht verwendet, so muss die
ID über die Webadresse (URL) übertragen werden. Der Tomcat-Application-Server
stellt dazu die komfortable Methode response.encodeURL(“Webadresse“) zur
Verfügung, der die Session-ID als Parameter an die URL anhängt.
5.3 Modul Titration
72
Das Listing 5.19 zeigt ein Beispiel zur Verwendung der oben genannten Methode
innerhalb eines HTML-Formulars.
Listing 5.19 - Verwendung der Sessions mit Hilfe der encodeURL()-Methode
Versteckte Formularfelder (Hidden Fields)
Um Informationen von einer Maske an eine andere weiterzuleiten, die aber für den
Anwender selber nicht relevant bzw. nicht sichtbar sein sollen, werden häufig
versteckte Elemente verwendet. Diese Elemente verwendet man in HTML-
Formularen und nennt sie Hidden Fields. Die Daten in den Feldern werden mit dem
Formular versendet (s. Listing 5.20) und können in der anderen Maske mit Hilfe der
Methode request.getParameter(…) ausgelesen werden (s. Listing 5.21).
Listing 5.20 – Senden einer Information mit einem Hidden Field
Listing 5.21 - Auslesen der Information aus einem Hidden Field
Automatische Weiterleitung (Forwarding)
Im Modul Titration soll in einigen Masken, ohne Eingriff des Anwenders, eine
automatische Weiterleitung oder Forwarding zu einer anderen Maske erfolgen. Solch
eine Situation ist z.B. eine Weiterleitung zu einer Fehlermeldungsmaske im Fehlerfall
oder eine Weiterleitung zur Übersichtsmaske bei einem erfolgreich abgeschlossenen
Messvorgang. Mit Hilfe der JSP-Aktion forward ist dies einfach zu realisieren (s.
Listing 5.22).
Listing 5.22 - Automatische Weiterleitung zur nächsten Maske
<a href="<%= response.encodeURL("./ProLab/link.jsp") %>">TestLink<a>
URL-Ergebniss: "./ProLab/link.jsp?sid=edb0e8665db4e9042fe0176a89aade16"
<form action="<%=response.encodeURL("/seite2.jsp")%>" method="post">
<input type="hidden" name="TestName" value="TestText">
<input type="submit" value="Absenden">
</form>
<%
String infoText = request.getParameter("TestName");
%>
Ergebnis in infoText: „TestText“
<jsp:forward page="seite2.jsp" />
5.3 Modul Titration
73
Datenverwaltung in JSPs
In ProLab werden alle relevanten Daten in Datenbanktabellen hinterlegt. Auch
Masken werden durch Informationen aus den Tabellen generiert. Diese Richtlinie
bzw. Vorgehensweise gilt auch für das Modul Titration.
In Kapitel 5.2.3 sind wir bereits auf die Datenbankverbindung und das
Datenbankobjekt eingegangen. Die Datenverwaltung (Selektierung und Speicherung)
in JSPs erfolgt dabei genauso wie in der Java-Klasse TitrationControler. Dabei wird
zunächst ein Datenbankobjekt aus dem Pool aufgenommen. Im Anschluss wird ein
SQLIQuery-Objekt instanziiert und die SQL-Statements mit addStatement() dem
Objekt übergeben. Zum Schluss werden die Statements mit der execute()-Methode
ausgeführt. Das Listing 5.23 soll den Ablauf der Datenverwaltung verdeutlichen.
Listing 5.23 - Instanziierung und Ausführung der SQL-Statements
Um die selektierten Daten auslesen und verarbeiten zu können, wird die
getResultValue()-Methode verwendet. Dabei werden der Name des Select-
Statements, die Spalte und die Zeile als Parameter der Methode übergeben. Einen
Beispielaufruf zum Auslesen eines Datums aus einem Query-Objekt zeigt das Listing
5.24.
Listing 5.24 - Auslesen der Daten aus dem Query-Objekt
DBConnection connection = DBConPoolObj.getDbCon();
SQLIQuery query = new SQLIQuery(connection);
query.addStatement("select", "SELECT name FROM test WHERE id = 2");
query.addStatement("insert", "INSERT INTO test (name, alter)
VALUES ('Alex',26));
query.addStatement("update", "UPDATE test SET name = 'Paul'
WHERE id = 5);
query.execute("select");
query.execute("insert");
query.execute("update");
String name;
int spalte = 1;
int zeile = 1;
name = query.getResultValue("select",spalte, zeile).toString().trim();
5.3 Modul Titration
74
Synchronisationsvorgang
Als erster Abschnitt der Titration erfolgt der Synchronisationsvorgang im ProLab-
System, bei dem die relative und absolute ID des Titrierautomaten ermittelt werden
soll. Dabei wird die sync_start.jsp-Seite als Einstiegsseite des Moduls Titration
angezeigt (s. Abb. 5.1). Die Masken sind in ProLab unter dem Logobereich stets in 3
Bereiche gegliedert:
1 Navigations-Bereich, 2 Haupt-Bereich (Content) und 3 Menü-Bereich.
Abb. 5.1 - Einstiegsseite des Moduls Titration
Um den Vorgang zu starten, klickt der Anwender im Content-Bereich auf den Start-
Button. Dies führt zu einer Weiterleitung auf die nächste Synchronisationsseite, bei
der die JavaBean TitrationStarterBean den TitrationControler im Hintergrund startet
und auf den Eingang von Daten im Netzwerk lauscht.
Abb. 5.2 - Durchführung der Synchronisation
5.3 Modul Titration
75
Auf der nun dargestellten Maske (Abb. 5.2) wird der Mitarbeiter aufgefordert, die
Synchronisation am Titrierautomaten auszuführen. Dazu wählt er die Sync-Methode
aus und startet den Vorgang. Die Seite aktualisiert sich alle 5 Sekunden und prüft, ob
der Sync-Vorgang abgeschlossen wurde. Der Anwender kann den Vorgang jeder
Zeit manuell abbrechen. Bei Abbruch gelangt er wieder zur Startseite. War der
Vorgang erfolgreich, so wird dem Anwender die neue Maske (Abb. 5.3) zur Kontrolle
des Synchronisationsvorgangs dargestellt. Der Labormitarbeiter vergleicht den Wert
an der Maske mit dem Wert am Ausdruck und bestätigt die Kontrolle bei Gleichheit.
Sollten die Werte nicht gleich sein, so muss ein neuer Synchronisationsvorgang
durchgeführt werden. Trat während des Vorgangs ein Fehler auf, so wird der
Vorgang kontrolliert beendet und eine Fehlermeldung ausgegeben (Abb. 5.4).
Abb. 5.3 - Überprüfung des Synchronisationsvorgangs
Abb. 5.4 - Fehlerfall im Synchronisationsvorgang
5.3 Modul Titration
76
Messvorgang
Nachdem der Synchronisationsvorgang abgeschlossen wurde, erfolgt die
Vorbereitung zu den Messungen. Dazu wird die Maske measure_set_pnr.jsp (Abb.
5.5) automatisch aufgerufen. Der Anwender trägt in die Suchmaske die gewünschte
Prüfungsnummer, zu der er die Messungen durchführen möchte, ein und erhält eine
Vorauswahl der Prüfungsnummern, die seiner Suche entsprechen. Dabei kann der
Anwender eine vollständige oder nur Teile einer Prüfungsnummer angeben und die
Datenbank gibt ihm die entsprechenden Prüfungen heraus.
Abb. 5.5 - Messvorbereitung: Auswahl der Prüfungsnummer
Nach der Auswahl der Prüfungsnummer werden der Messvorgangstabelle
automatisch Messungen zugewiesen (s. Abb. 5.6). Pro Prüfung ist es jeweils eine
Messung für die Probe und eine für die Blindprobe. Nachdem der Anwender alle
Prüfungen mit den zugehörigen Messungen in der Tabelle eingetragen hat, bestätigt
er die Messvorgangstabelle, indem er den Messvorgang startet.
5.3 Modul Titration
77
Abb. 5.6 - Abgeschlossene Messvorbereitung am ProLab-System
Nachdem der Messvorgang im ProLab-System gestartet (s. Abb. 5.7) und die
Messungen am Titrierautomaten vorbereitet wurden, startet der Labormitarbeiter den
Messvorgang direkt am Titrierautomaten.
Abb. 5.7 - ProLab-System ist bereit für die Messdatenerfassung
5.3 Modul Titration
78
Während des laufenden Messvorgangs aktualisiert sich die Maske alle 5 Sekunden
automatisch und gibt den Verlauf bzw. den Status der Messungen wieder (Abb. 5.8).
In dieser Maske kann der Vorgang ebenfalls manuell abgebrochen werden.
Abb. 5.8 - laufender Messvorgang
Sind alle Messungen abgeschlossen, so wird dem Labormitarbeiter in der Maske
measure_control.jsp (Abb. 5.9) noch einmal die Messvorgangstabelle angezeigt und
ein Hinweis zur Einsicht bzw. Bearbeitung der Messdaten gegeben.
Abb. 5.9 - Abgeschlossener Messvorgang
5.3 Modul Titration
79
Messdatenübersicht
Um die Korrektheit der ermittelten Messdaten zu gewährleisten, muss der
Labormitarbeiter nach dem abgeschlossenen Messvorgang eine Einsicht in die
Messdatenübersicht durchführen und die Messdaten bestätigen (Abb. 5.10
editTitration.jsp). Wie bereits im Kapitel 4.3.2 Absatz Messdatenprüfung
beschrieben, vergleicht der Labormitarbeiter die Werte im System mit den Werten
auf dem Ausdruck. Anschließend hat der Anwender die Möglichkeit, einen Datensatz
zu speichern, zu löschen oder manuell zu bearbeiten.
Abb. 5.10 - Messdatenübersicht
80
6 Test
Der Software-Lebenszyklus Test befasst sich mit der Qualität einer Applikation.
Dabei wird die Anwendung auf vorhandene Fehler geprüft und eine Bewertung bzw.
eine Aussage über die Qualität der Software gefällt. Grundsätzlich lässt sich der Test
in zwei Phasen unterteilen:
Verifikation,
Validierung.
Verifikation
In der Verifikation wird eine Software bezüglich ihrer Korrektheit getestet, d.h. man
befasst sich hauptsächlich mit der Frage: „Wurde die Software richtig entwickelt?“.
Um die Korrektheit überprüfen zu können, werden die Sofwarekomponenten, wie
Klassen oder Methoden, einzeln auf das richtige Arbeiten und Ausliefern korrekter
Ergebnisse getestet.
Validierung
Das Gegenstück zur Verifikation ist die Validierung. In dieser erfolgt keine
Überprüfung der inneren Komponenten, sondern das Testen der eigentlichen
Applikation selbst. Dabei befasst man sich mit der Fragestellung: „Wurde die richtige
Software entwickelt?“. Dazu werden die in der Analyse festgelegten spezifischen
Anforderungen der Applikation gegenüber gestellt und verglichen.
In Softwareprojekten ist es sehr wohl möglich, dass eine Anwendung korrekt
verifiziert, jedoch nicht validiert wird. Das heißt, dass ein entwickeltes Programm
einwandfrei funktioniert, aber gar nicht oder nur teilweise die vom Auftraggeber
gestellten Anforderungen erfüllt und somit nicht zu gebrauchen ist.
6.1 Verifikation mit JUnit Tests
81
6.1 Verifikation mit JUnit Tests
Zur Verifizierung der Applikationen SocketReader und TitrationControler werden
innerhalb der NetBeans-Entwicklungsumgebung JUnit-Tests durchgeführt. Das JUnit
ist ein Framework, welches zum modulbasierten Testen von Java-Programmen dient
und dabei die einzelnen Komponenten automatisiert und wiederholbar prüft. Somit
wird gewährleistet, dass Programmierfehler während des Entwicklungsprozesses
frühzeitig erkannt und behoben werden können.
Das Vorgehen der JUnit Tests basiert auf Vergleiche der resultierenden Ergebnisse
mit den zu erwartenden Ergebnissen nach einem Test. Somit wird die korrekte
Funktionalität einer Klasse oder Methode überprüft. Dabei hat jeder Test folgenden
grundsätzlichen Ablauf: Testumgebung aufbauen => Test durchführen => Test
qualifizieren => Testumgebung aufräumen.
JUnit Tests werden ebenfalls in Java entwickelt und befinden sich im selben Projekt-
Ordner, in dem auch die Applikationen enthalten sind. Jedoch werden die Tests im
Unterordner „Test Packages“ und die Programme im Unterordner „Source Packages“
verwaltet.
Für das zu testende Programm wird zunächst eine Testklasse erstellt, die den
Namen der Anwendung mit dem Anhang „Test“ (z.B. SocketReaderTest.java)
beinhaltet. Innerhalb der Testklasse werden in JUnit Annotationen (Metainfor-
mationen) verwendet, die den automatisierten Ablauf eines Tests mit
Vorbedingungen und Nachbedingungen ermöglichen. Um die Testumgebung
komplett aufzubauen, erfolgt zunächst ein Aufruf der setUp()-Methode mit der
@Before-Annotation. In dieser Methode können die Vorbedingungen, z.B. ein
Verbindungsaufbau zu einer Datenbank, vor jeder zu testenden Methode
durchgeführt werden. Das Gegenstück dazu ist die tearDown()-Methode mit der
@After-Annotation. Diese kann verwendet werden, um nach jedem abgeschlossenen
Test einer Methode die Testumgebung wieder abzubauen.
Das eigentliche Testen einer Methode wird mit der @Test-Annotation angeführt. Der
jeweilige Methodenname führt das Präfix „test“ vor der eigentlichen Bezeichnung. Im
Verlauf der Testdurchführung werden die zu testenden Methoden automatisiert
ausgeführt und deren Ergebnisse mit den erwarteten Ergebnissen verglichen.
6.1 Verifikation mit JUnit Tests
82
Für diesen Vorgang existieren verschiedene JUnit-Methoden, die je nach Bedarf
eingesetzt werden können und deren Funktion größtenteils durch die Namens-
gebung deutlich wird.
static void assertEquals ( Object expected , Object actual )
static void assertTrue ( Boolean condition )
static void assertFalse ( Boolean condition )
static void assertSame ( Object expected , Object actual )
static void assertNotSame ( Object unexpected , Object actual )
static void assertNull ( Object object )
static void assertNotNull ( Object object )
static void fail()
Es folgt eine kurze Erläuterung einiger Methoden. Die assertEquals()-Methode prüft
z.B. zwei Werte auf Gleichheit, in dem sie den erwarteten Wert und den im Test
ermittelten Wert als Parameter erhält und vergleicht. assertNull() prüft ein Objekt auf
den erwarteten Rückgabewert null. Beim Aufruf der fail()-Methode führt dies stets
zum fehlschlagen eines Test.
Nachdem ein Test durchlaufen und die darin angewendete JUnit-Methode
durchgeführt wurde, liefert das Framework stets ein Ergebnis zurück. Im Fehlerfall
weißt eine rote „FAILED“ Meldung auf ein fehlschlagen der Testmethode hin. Ein
erfolgreicher Test wird mit der grünen Meldung „PASSED“ quittiert. Nach Abschluss
aller JUnit-Tests erhält der Entwickler eine Übersicht aller fehlgeschlagenen und
erfolgreich durchlaufenen Tests.
Im Folgenden Listing 6.1 werden zwei exemplarische JUnit-Tests dargestellt. Der
erste Test prüft die Socket-Verbindung des SocketReader-Objekts. Ist der Socket
verbunden, so wird der Test als erfolgreich gewertet. Der zweite Test sendet dem
SocketReader von außen ein Abbruch-/Unterbrechungssignal, damit dieser die
Socket-Verbindung kontrolliert schließt und sich beendet.
In beiden Tests wird als Vorbedingung eine TitrierDatenSenden-Klasse instanziiert,
welche als Gegenseite der Socket-Verbindung agiert.
6.1 Verifikation mit JUnit Tests
83
Listing 6.1 - Komponentenbasiertes Testen mit JUnit
public class SocketReaderTest {
import net.miele.de.prolab.sys.Titration.TitrierDatenSenden;
TitrierDatenSenden sender;
/* Test aufbauen */
@Before
public void setUp(){
sender = new TitrierDatenSenden();
sender.start();
}
/* Test abbauen */
@After
public void tearDown() {
sender.closeConnection();
}
/* Test1 durchführen */
@Test
public void testRun() {
try{
SocketReader instance = new SocketReader("gtkewlx11", "33333");
instance.start();
Thread.sleep(1000);
boolean expResult = true;
boolean result = instance.getIsConnected();
assertEquals(expResult,result);
} catch (Exception ex){
fail("Excepition in Methode: run()");
}
}
/* Test2 durchführen */
@Test
public void testSetThreadInterrupt() {
try{
SocketReader instance = new SocketReader("gtkewlx11", "33333");
instance.start();
Thread.sleep(1000);
if(instance.getIsConnected() == true){
instance.setThreadInterrupt();
Thread.sleep(5000);
Thread.State expResult = Thread.State.TERMINATED;
Thread.State result = instance.getState();
assertEquals(expResult, result);
} else {
fail("No connection to Socket.");
}
} catch (Exception ex){
fail("Excepition in Methode: setThreadInterrupt()");
}
}
}
6.2 Validierung des Moduls Titration
84
6.2 Validierung des Moduls Titration
Neben den JUnit Tests, die als White-Box-Testverfahren das direkte Prüfen des
Applikationscodes durchführen, erfolgt in der Validierung das Testen und Bewerten
einer Software auf ihr äußeres Verhalten.
Die Anwendungsprüfung erfolgt von einer oder mehreren außenstehenden
Personen, die an der Entwicklung bzw. Programmierung nicht teilnehmen und somit
die Software nicht kennen. Jedoch haben die Personen sowohl Kenntnisse über die
spezifischen Anforderungen, die die Anwendung zu erfüllen hat, als auch fachliches
Wissen, um die Funktionen der Anwendung zu testen. Dieses Verfahren nennt man
Black-Box-Test.
Die Tester prüfen die Anwendung und dokumentieren die auftretenden Fehler. Diese
werden dem Entwickler bzw. Entwicklerteam bekannt gegeben. Die vorgefundenen
Fehler werden vom Entwickler behoben und die Software als neue Version dem
Tester zur Verfügung gestellt. Das Black-Box-Testverfahren wird solange wiederholt,
bis alle spezifischen Anforderungen erfüllt sind und keine Fehler mehr auftreten.
Als Tester des Moduls Titration wurden in diesem Projekt mein Betreuer sowie zwei
Mitarbeiter und der Auftraggeber aus dem Labor „Verfahrensprüfung“ eingesetzt.
Im Folgenden stellt die Tabelle 6.1 die spezifischen Anforderungen dar, auf die das
Modul Titration geprüft wurde.
Anforderungen Vorhanden / Erfüllt
Sync-Vorgang (Synchronisationsvorgang) vor Messvorgang. Ja
Sync-Vorgang als Einstiegs-/Startseite. Ja
Automatische Seitenaktualisierung während des Sync-Vorgangs. Ja
Manueller Abbruch des Sync-Vorgangs möglich. Ja
Sinnvolle, verständliche (Fehler-)Meldung bei Abbruch oder im Fehlerfall.
Ja
Nach dem Sync-Vorgang automatische Weiterleitung zur Kontrollseite. Ja
Vorbereitung der Messungen im Modul Titration. Ja
Suchfunktion zur vereinfachten Eingabe der Prüfungsnummern. Ja
Automatische Eintragung zweier Messungen pro Prüfungsnummer in der Messtabelle.
Ja
Automatische Aktualisierung der Maske während des laufenden Messvorgangs.
Ja
Manueller Abbruch des Messvorgangs möglich. Ja
6.2 Validierung des Moduls Titration
85
Übersichtliche Ausgabe der gemessenen Daten in der Maske „Messdatenübersicht“.
Ja
Bei manuellem Abbruch oder im Fehlerfall, sollen bereits erfolgreich abgeschlossene Messungen nicht verloren gehen und in der Maske „Messdatenübersicht“ angezeigt werden.
Ja
Weiterführende Datenerfassung bei Absturz des Browsers/Terminals. Ja
Jederzeitiger Zugriff auf die Messdatenübersicht von einem anderen Terminal aus möglich. Auch bei laufender Messung.
Ja
Bei Absturz und Neustart des Browsers/Moduls, wird geprüft ob zurzeit ein Messvorgang durchgeführt wird. Der Benutzer wird darauf hingewiesen und kann den Messvorgang manuell abbrechen.
Ja
Tabelle 6.1 - Validierung des Moduls Titration
In der Validierung der Anwendung sind einige spezifische Anforderungen
aufgekommen, die in den Phasen Analyse und Entwurf nicht bekannt bzw. nicht
ersichtlich waren. Es wurden jedoch alle Anforderungen erfolgreich implementiert
und das Projekt mit der Abnahme des Auftraggebers abgeschlossen.
86
7 Fazit und Ausblick
Fazit
Diese Bachelorarbeit befasste sich mit dem Prüfprozess Titration. Dabei sollte der
vorhandene Prozess, welcher im Labor Verfahrensprüfung eingesetzt wird, auf das
von Miele zukünftig eingesetzte Prüfungsverwaltungssystem ProLab abgebildet und
anschließend umgesetzt werden. Eine wichtige Voraussetzung war dabei, dass der
Ablauf des vorhandenen Prüfprozesses durch das ProLab-System vereinfacht und
weitestgehend automatisiert wird. Dazu wurde das Modul Titration konzeptioniert und
in das System ProLab implementiert.
Es bestand zu Anfang der Bachelorarbeit die Frage, ob der Prüfprozess Titration und
die damit einbezogene Messdatenerfassung grundsätzlich in das Prüfungs-
verwaltungssystem ProLab eingebunden und automatisiert werden kann. Anhand der
von mir durchgeführten Analyse wurde festgestellt, dass eine Einbindung aus
technischer Sicht (Hardware und Software) grundsätzliche möglich ist. Des Weiteren
wurden bei der Analyse Schwächen bzw. negative Aspekte des vorhandenen
Prüfprozesses (starke Fehleranfälligkeit und hoher Zeitaufwand) aufgezeigt, die eine
Einbindung des Prozesses in das neue System ProLab für sinnig und notwendig
erwiesen.
In der Konzeption wurden die vom Auftraggeber grob definierten Anforderungen
durch das von mir erstellte Pflichtenheft konkretisiert und festgelegt. Im
anschließenden Entwurf wurde die Architektur des Software-Systems (Modul
Titration) und des Hardware-Systems (Com-Server), die zur Umsetzung der
spezifischen Anforderungen benötigt wurden, festgelegt.
Bei der Implementierung wurde die in der Konzeption definierte Architektur mit den
im Kapitel „Grundlagen“ genannten Sprachen und Techniken als webbasierter
Workflow realisiert.
6.2 Validierung des Moduls Titration
87
Die Realisierung erfolgte dabei nicht immer problemlos. Eine vom Auftraggeber nicht
bekanntgegebene durchgeführte Softwareaktualisierung am Titrierautomaten führte
zu einem umstrukturierten Reportergebnis, der vom Parser nicht mehr interpretiert
werden konnte. Die erfolgte Softwareaktualisierung war nicht vorhersehbar und
führte zu einer zeitlichen Verzögerung innerhalb des Projekts.
In den abschließenden Tests, welche grundsätzlich als Verifikations- und
Validierungstests durchgeführt wurden, wurde die Software auf Realisierung der
spezifischen Anforderungen und möglich aufkommende Fehler geprüft. Beide
Testverfahren lieferten erfolgreiche Ergebnisse.
Das von mir realisierte Projekt wurde sowohl von den Mitarbeitern als auch vom
Verantwortlichen des Labors Verfahrensprüfung wohlwollend angenommen, da es
den Arbeitsablauf verbesserte und die genannten negativen Aspekte behob.
Zusammenfassend können die gestellten Anforderungen als erfüllt und die
Implementierung als abgeschlossen betrachtet werden.
Ausblick
Das bereits implementierte Modul Titration kann zusätzlich erweitert werden, indem
der Kalibriervorgang in das Modul eingebunden wird.
Der beim Titrationsverfahren angewendete Titrierautomat muss einmal in der Woche
kalibriert werden. Die Kalibrierung ist nötig, um die Korrektheit der Messergebnisse
einer Messung zu gewährleisten. Der Kalibriervorgang ist dabei ähnlich dem
Titrationsvorgang. Dort fallen ebenfalls Messdaten an, die dokumentiert werden
müssen.
Durch einen relativ geringen Aufwand kann das Modul erweitert werden, um einen
weitestgehend automatisierten Kalibriervorgang am ProLab-System durchführen zu
können. Die Messdaten würden dabei ebenfalls in einer Datenbank gespeichert und
dem Labormitarbeiter zur Kontrolle in einer Übersichtsmaske dargestellt werden.
88
8 Abbildungsverzeichnis
Abb. 2.1 - Miele Labordatenbank ................................................................................ 5
Abb. 2.2 - Hierarchischer Aufbau eines Prüfauftrags .................................................. 7
Abb. 2.3 - Miele ProLab-System ................................................................................. 8
Abb. 2.4 - Funktionsweise zwischen LabDB und ProLab ......................................... 10
Abb. 2.5 - Beispiel einer Relation ............................................................................. 15
Abb. 2.6 - Struktur des Tomcat-Applikation-Servers ................................................. 18
Abb. 3.1 - Titrationsverfahren ................................................................................... 24
Abb. 3.2 - Titrierautomat mit Rondell ........................................................................ 25
Abb. 4.1 - Systemkomponenten v.l.: Drucker, Tastatur, Titrino, Rondel und Waage 29
Abb. 4.2 - RS232/USB Box ....................................................................................... 29
Abb. 4.3 - Aufbau der Systemkomponenten im Labor .............................................. 30
Abb. 4.4 - Com-Server und Terminal im Labor Verfahrensprüfung .......................... 36
Abb. 4.5 - Systemkomponenten und Kommunikation ............................................... 37
Abb. 4.6 - Ablaufdiagramm Titration Teil1 ................................................................ 38
Abb. 4.7 - Ablaufdiagramm Titration Teil2 ................................................................ 39
Abb. 4.8 - Ablaufdiagramm Titration Teil3 ................................................................ 40
Abb. 4.9 - Zusammenhang eines Messvorgangs ..................................................... 42
Abb. 4.10 - Klassendiagramm Titration..................................................................... 45
Abb. 5.1 - Einstiegsseite des Moduls Titration .......................................................... 75
Abb. 5.2 - Durchführung der Synchronisation ........................................................... 75
Abb. 5.3 - Überprüfung des Synchronisationsvorgangs............................................ 76
Abb. 5.4 - Fehlerfall im Synchronisationsvorgang .................................................... 76
Abb. 5.5 - Messvorbereitung: Auswahl der Prüfungsnummer ................................... 77
Abb. 5.6 - Abgeschlossene Messvorbereitung am ProLab-System .......................... 78
Abb. 5.7 - ProLab-System ist bereit für die Messdatenerfassung ............................. 78
Abb. 5.8 - laufender Messvorgang ............................................................................ 79
Abb. 5.9 - Abgeschlossener Messvorgang ............................................................... 79
Abb. 5.10 - Messdatenübersicht ............................................................................... 80
89
9 Listingverzeichnis
Listing 2.1 - Beispiel eines Create-Befehls ............................................................... 15
Listing 2.2 - Beispiel eines Insert-Befehls ................................................................. 16
Listing 2.3 - Beispiel eines Select-Befehls ................................................................ 16
Listing 2.4 - Beispiel eines Grant-Befehls ................................................................. 16
Listing 2.5 - Beispiel eines Revoke-Befehls .............................................................. 16
Listing 4.1 - Reportauszug vom 848 Titrino plus ....................................................... 31
Listing 5.1 - Include-Beispiel ..................................................................................... 49
Listing 5.2 - Verwendung der Run()-Methode ........................................................... 54
Listing 5.3 - Instanziierung der benötigen Klassen und Aufbau der Socketverbindung
................................................................................................................................. 55
Listing 5.4 - Abbruchbedingungen und Datenzwischenspeicherung ........................ 56
Listing 5.5 - Interrupt-Methode .................................................................................. 56
Listing 5.6 - Konstruktoren der Klasse TitrationControler ......................................... 57
Listing 5.7 - Konfigurationsmethode readConfigData() ............................................. 57
Listing 5.8 - Interner Aufbau des TitrationControlers ................................................ 58
Listing 5.9 - readConfigData()-Methode zur Ermittlung der Konfigurationsdaten ...... 59
Listing 5.10 - Aufbau der init()-Methode ................................................................... 60
Listing 5.11 - connectClient()-Methode für die Socketverbindung ............................ 61
Listing 5.12 - while-Schleife in der getDatasets()-Methode....................................... 62
Listing 5.13 – Reportauszug mit Beispiel-Messdaten ............................................... 63
Listing 5.14 - Aufbau der getNextDataset()-Methode ............................................... 64
Listing 5.15 – Parsing-Vorgang in der saveData()-Methode ..................................... 67
Listing 5.16 - Zusammenbau des Select-Statements ............................................... 68
Listing 5.17 - Ausführung des Insert- und Update-Befehls ....................................... 69
Listing 5.18 - Aufbau der TitrationControler Bean ..................................................... 70
Listing 5.19 - Verwendung der Sessions mit Hilfe der encodeURL()-Methode ......... 72
Listing 5.20 – Senden einer Information mit einem Hidden Field .............................. 72
Listing 5.21 - Auslesen der Information aus einem Hidden Field .............................. 72
Listing 5.22 - Automatische Weiterleitung zur nächsten Maske ................................ 73
Listing 5.23 - Instanziierung und Ausführung der SQL-Statements .......................... 74
Listing 5.24 - Auslesen der Daten aus dem Query-Objekt ........................................ 74
Listing 6.1 - Komponentenbasiertes Testen mit JUnit .............................................. 84
90
10 Tabellenverzeichnis
Tabelle 4.1 - Status der Messungen im ProLab-System........................................... 43
Tabelle 5.1 - Gültigkeitsbereiche einer JavaBean in JSPs ....................................... 50
Tabelle 5.2 - Übersicht der Datenbanktabellen ......................................................... 58
Tabelle 5.3 - Parser-Tabelle ..................................................................................... 60
Tabelle 5.4 - Beispieleinträge in der newData-Hashtable ......................................... 65
Tabelle 6.1 - Validierung des Moduls Titration .......................................................... 86
91
11 Literaturverzeichnis
1 Miele im Kurzportrait - Miele
http://www.miele-nachhaltigkeit.de/international/ de/nachhaltigkeit/3865.htm
[Online; Stand August 2011]
2 Nachhaltigkeitsbericht 2011 - Miele
http://www.miele-nachhaltigkeit.de/ international/de/nachhaltigkeit/start.html [Online; Stand August 2011]
3 Unternehmensprofil - Werum Software & System AG
http://www.werum.de/de/werum/corpstrat/corpstrat.jsp
[Online; Stand August 2011]
4 HyperTest - Werum Software & System AG
http://www.werum.de/de/mdm/prod/hypertest/hypertest.jsp?top=1
[Online; Stand August 2011]
5 Java Message Service Provider – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Java_Message_Service
[Online; Stand August 2011]
6 Java (Programmiersprachen) – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Java_(Programmiersprache) [Online; Stand August 2011]
7 Hypertext Markup Language (HTML) - Wikipedia Enzyklopädie http://de.wikipedia.org/wiki/Hypertext_Markup_Language
[Online; Stand August 2011]
8 Cascading Style Sheets (CSS) - Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/Cascading_Style_Sheets [online; Stand August 2011]
9 JavaServer Pages (JSP) – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/JavaServer_Pages
[Online; Stand August 2011]
10 JSP Lebenszyklus von JSPs - <jsptutorial/> http://www.jsptutorial.org/content/lifecycle
[Online, Stand August 2011]
6.2 Validierung des Moduls Titration
92
11 Structered Query Language (SQL)
Vorlesungsunterlagen zur Vorlesung Datenbanken
bei Herrn Prof. Dr. Thomas Weik [Stand Sommersemester 2009]
12 Apache Tomcat
http://tomcat.apache.org/ [Online, Stand August 2011]
13 Apache Tomcat Architektur
Pro Apache Tomcat 6 von Mathew Moodie; Verlag „apress“ 2007
14 Säure-Base-Titration – Wikipedia Enzyklopädie
http://de.wikipedia.org/wiki/S%C3%A4ure-Base-Titration
[Online, Stand August 2011]
15 Beans in JSP - <jsptutorial />
http://www.jsptutorial.org/content/beans
[Online, Stand August 2011]