DA Riedel Version Finishopenifctools.com/homepage_s/uni/DA_Riedel.pdf · Bauhaus-Universität Weimar Fakultät Bauingenieurwesen Lehrstuhl Informatik im Bauwesen DIPLOMARBEIT IMPLEMENTIERUNG

Bauhaus-Universität Weimar

Fakultät Bauingenieurwesen

Lehrstuhl Informatik im Bauwesen

D I P L O M A R B E I T

IMPLEMENTIERUNG EINER APPLIKATION

ZUR VERWALTUNG UND AUSWERTUNG

VON VERSUCHSDATEN

Thomas Riedel

Weimar, Dezember 2005

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Vorwort

Vorwort

Für die Hilfe und Unterstützung, die mir bei der Bearbeitung des Themas zu teil wurde,

möchte ich mich bei Prof. Dr.-Ing. K. Beucke und Dipl.-Ing. E. Tauscher vom Lehrstuhl

Informatik im Bauwesen sowie Dipl.-Ing. H. Müller von der Professur Verkehrsbau

bedanken.

Mein ganz besonderer Dank gilt sowohl meinen Eltern als auch meinen Großeltern, die

es mir durch ihre jahrelange Unterstützung auch in schwierigen Situationen

ermöglichten, mich persönlich und beruflich weitestgehend frei entwickeln zu können.

Weimar, Dezember 2005

Thomas Riedel

1

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Inhaltsverzeichnis

Inhaltsverzeichnis

Vorwort.............................................................................................................................1

Inhaltsverzeichnis ............................................................................................................2

Abkürzungsverzeichnis ...................................................................................................4

1 Einleitung..................................................................................................................51.1 Gegenstand.........................................................................................................5

1.2 Aufbau der Arbeit ..............................................................................................6

2 Ausgangssituation ....................................................................................................72.1 Prüfstand ............................................................................................................7

2.1.1 Versuchsdurchführung.............................................................................. 8

2.1.2 Weiterverarbeitung der Prüfdaten........................................................... 10

2.2 Vorhandene Lösungen .....................................................................................12

2.2.1 Datenbank ............................................................................................... 12

2.2.2 Visualisierung ......................................................................................... 13

3 Lösungskonzept......................................................................................................153.1 Modifikationen an der Prüfdatei ......................................................................15

3.2 Datenbankentwurf............................................................................................19

3.2.1 Entity Relationship Modell ..................................................................... 19

3.2.2 Konzept der Versuchsdatenbank ............................................................ 21

3.2.3 SQL......................................................................................................... 22

3.2.4 ODBC ..................................................................................................... 24

3.3 Vorbetrachtung zur Visualisierung der Prüfdaten ...........................................27

3.3.1 Charakteristik der zu visualisierenden Kurven....................................... 27

3.3.2 Punktreduzierung mittels Anstiegsdifferenz........................................... 28

3.3.3 Punktreduzierung mittels Linienglättung................................................ 31

3.4 Synchronisation der Prüfdateien......................................................................37

3.5 Speicherung der Prüfdateien............................................................................38

3.5.1 GZIP Kompressionsformat ..................................................................... 39

4 Implementierung....................................................................................................404.1 Auswahl der Technologien ..............................................................................40

4.1.1 MS-Access .............................................................................................. 40

4.1.2 Java ......................................................................................................... 40

2

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Inhaltsverzeichnis

4.2 Versuchsdatenbank ..........................................................................................41

4.3 Java-Applikation..............................................................................................44

4.3.1 Funktionsweise ....................................................................................... 44

4.3.2 Struktur ................................................................................................... 45

4.3.3 Datenbankzugriff .................................................................................... 46

4.3.4 Datenbankverbindung - DbVerbindungsManager.java.............. 52

4.3.5 Einpflegen von Versuchsdaten - DbMaske.java .............................. 52

4.3.6 Einlesen der Prüfdatei - DbParser.java .......................................... 54

4.3.7 Komponenten der Nutzeroberfläche....................................................... 55

4.3.8 Koordinatensystem - package coordinateSystem ................... 56

4.3.9 Grafische Darstellung ............................................................................. 56

4.3.10 Synchronisierung .................................................................................... 58

4.3.11 Speicherung/Archivierung ...................................................................... 60

5 Zusammenfassung .................................................................................................62

6 Bedienungsanleitung..............................................................................................646.1 Installation .......................................................................................................64

6.1.1 Systemvoraussetzungen .......................................................................... 64

6.1.2 Installation .............................................................................................. 64

6.2 Bedienung ........................................................................................................65

6.2.1 Konfigurieren der Datenbankverbindung ............................................... 65

6.2.2 Einpflegen von Daten ............................................................................. 65

6.2.3 Einlesen einer Prüfdatei .......................................................................... 66

6.2.4 Grafische Darstellung ............................................................................. 67

6.2.5 Drucken und Speichern........................................................................... 69

6.2.6 Layout der Anwendung .......................................................................... 69

Abbildungsverzeichnis...................................................................................................70

Codelisting ......................................................................................................................72

Tabellenverzeichnis .......................................................................................................73

Literaturverzeichnis ......................................................................................................74

Anhang............................................................................................................................76

Selbständigkeitserklärung.............................................................................................77

Thesen .............................................................................................................................78

3

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Abkürzungsverzeichnis

Abkürzungsverzeichnis

API - Application Program Interface

DB - Datenbank

DBMS - Datenbankmanagementsystem

ERM - Entity Relationship Modell

GIS - Geo-Informationssystem

JDBC - Java Database Connectivity

JDK - Java Development Kit

ODBC - Open Database Connectivity

SQL - Standard Query Language

URL - Uniform Resource Locator

XML - Extensible Markup Language

4

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Einleitung

1 Einleitung

1.1 Gegenstand

Für die effiziente Auswertung und Bearbeitung von Versuchsdaten ist deren

Visualisierung notwendig und sinnvoll. In vielen Ingenieuranwendungen werden dazu

grafische Darstellungen innerhalb von Koordinatensystemen verwendet. Dadurch sind

Ingenieure in der Lage Zusammenhänge schnell und komfortabel zu erkennen und

Probleme zu lösen.

Um eine Analyse von Lagerelementen durchführen zu können (z.B. Brückenlager),

werden an der Professur Verkehrsbau verschiedene Untersuchungen an Probekörpern

mit Hilfe eines servohydraulischen Lagerprüfstandes vorgenommen. Die Probekörper

werden dabei Belastungen ausgesetzt, die z.B. an realen Brückenlagern entstehen

können. Durch die gewonnenen Erkenntnisse und Messdaten haben Ingenieure die

Möglichkeit vorauszusagen, wie sich die verschiedenen Probekörper unter bestimmten

Belastungssituationen verhalten. Die Analysen werden im Auftrag der Hersteller der

jeweiligen Lagerelemente durchgeführt. Außerdem wird der Prüfstand innerhalb des

Verkehrsbaulehrstuhles zu Forschungszwecken genutzt, die zur Neuentwicklung und

Optimierung von Lagerelementen dienen.

Die Verwaltung der unterschiedlichen Prüfvorgänge ist aufgrund der Vielfalt der

Parameter, welche einen Versuchsdurchgang beschreiben können, sehr aufwendig. Zum

Beispiel können Druckversuche, Schubversuche, Momentenversuche und andere frei

definierbare Versuche an dem Prüfstand durchgeführt werden. An jedem

Versuchsdurchgang können mehrere Probekörper beteiligt sein, die viele

unterschiedliche Eigenschaften besitzen. Um die Archivierung der gesamten

Prüfvorgänge zu erleichtern, wurde im Rahmen einer Studienarbeit [1] eine Visual-

Basic-Applikation auf Basis einer MS-Access Datenbank entwickelt. Mit Hilfe dieser

Datenbank werden alle beschreibenden Versuchsdaten innerhalb der Datenbank

gespeichert.

Neben den Parametern die den Versuchsdurchgang beschreiben, fallen die eigentlichen

Messdaten an, welche vom Prüfstand generiert werden. Das sind letztlich die Daten,

welche von den Ingenieuren ausgewertet werden müssen, um zuverlässige Aussagen

5

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Einleitung

über das Verhalten der Probekörper treffen zu können. Die Analyse der Messdaten

erfolgt durch das Erzeugen von Kurvenverläufen innerhalb von Koordinatensystemen.

Um die Visualisierung speziell an die Bedürfnisse des Verkehrsbaulehrstuhles

anzupassen wurde eine Java-Applikation zur grafischen Darstellung entwickelt [2].

Die Evaluierung beider Arbeiten [1][2], lieferte Ansätze zur Verbesserung der

Datenbank sowie der Java-Applikation. In dieser Diplomarbeit werden diese

Vorschläge aufgegriffen, die Datenbank neu strukturiert und die momentan

vorhandenen Insellösungen zur Bedienung der Datenbank in einer Java-Applikation

vereint.

1.2 Aufbau der Arbeit

Zunächst wird in Kapitel 2 ein Überblick über die Versuchsabläufe an der Prüfmaschine

der Professur Verkehrsbau gegeben. Darauf folgend wird erläutert, wie die erzeugten

Prüfdaten der Versuche weiterverarbeitet werden, und es werden Probleme aufgezeigt,

die sich bei der Speicherung der Daten innerhalb der vorhandenen Datenbank sowie bei

der grafischen Darstellung ergeben.

Danach werden in Kapitel 3 Lösungskonzepte erarbeitet. Diese Betrachtungen umfassen

drei Teilbereiche. Als erstes wird das Format der Prüfdateien des Prüfstands strukturiert

und optimiert, damit mit der zu entwickelnden Java-Applikation ein automatisches

Einlesen dieser Dateien umgesetzt kann. Danach wird ein Datenbankmodell entworfen,

das den Anforderungen zum Speichern der Versuchsdaten gerecht wird. Daraufhin

werden Überlegungen zur grafischen Aufbereitung der Messdaten vorgestellt und

diskutiert.

In Kapitel 4 werden die Lösungskonzepte aufgegriffen und anhand der

Implementierung einer MS-Access Datenbank sowie einer Java-Applikation umgesetzt.

Die entwickelte MS-Access Datenbank versuch.mdb sowie die implementierte Java-

Applikation Viewer-Tool-2.0 sind auf der Begleit-CD zu dieser Arbeit zu finden. Als

Entwicklungsumgebung für die Java-Applikation diente die Eclipse Platform Version

3.1.0.

6

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Ausgangssituation

2 Ausgangssituation

Im folgenden Abschnitt wird ein Überblick über die Versuchsabläufe am Prüfstand des

Verkehrsbaulehrstuhls gegeben. Weiterhin wird die Entstehung der Messdaten, sowie

deren Weiterverarbeitung und Auswertung beleuchtet. Dabei werden momentan

auftretende Probleme und Nachteile angeführt.

2.1 Prüfstand

Der servohydraulische Prüfstand DPD-1500 an der Professur Verkehrsbau ist vielseitig

einsetzbar. Einerseits werden im Auftrag der Hersteller der Probekörper Versuche zur

Analyse der Eigenschaften dieser Probekörper durchgeführt, andererseits führen die

Mitarbeiter der Professur Verkehrsbau eigene Forschungsversuche durch. Diese haben

die Entwickelung neuer Brückenlager zum Ziel. Abbildung 2-1 soll dem Leser einen

Eindruck von dem Prüfstand und den damit zu untersuchenden Probekörpern

vermitteln.

Abbildung 2-1 links: Prüfstand an der Professur Verkehrsbau; rechts Probekörper

7


2.1.1 Versuchsdurchführung

Die gesamte Kontrolle und Steuerung der Versuchsdurchführung übernimmt ein am

Prüfstand angeschlossener Computer. Nachdem der Probekörper zwischen den

Druckplatten der Prüfmaschine justiert wurde, wird der Prüfstand in Position gefahren

und der Probekörper wird einer bestimmten Belastung ausgesetzt. Abbildung 2-2 zeigt

schematisch die Versuchsdurchführung.

Abbildung 2-2 Skizze zur Versuchsdurchführung

Mit Hilfe der Prüfmaschine werden reale Bedingungen simuliert, wie sie z.B. an

Brückenlagern auftreten können. Die Zeitdauer der Belastung variiert und hängt vom

jeweiligen Versuchstyp ab. Beispielsweise können sich Dauerschwellversuche über

einen Zeitraum von mehreren Wochen erstrecken, während Druck- oder Schubversuche

mit Belastungsdauern von maximal einer Stunde durchgeführt werden. Als Ergebnis

dieser Versuche, liefert der Prüfcomputer Messdaten zurück, die in einfacher Textform

in einer Prüfdatei gespeichert werden. Innerhalb dieser Prüfdatei werden Angaben wie

Versuchsart, Datum und Uhrzeit des Versuches sowie Bezeichnungen und Einheiten der

aufgezeichneten Messdaten festgehalten. Abbildung 2-3 zeigt den Inhalt einer

standardmäßigen Prüfdatei für einen Druckversuch.

8


Druckversuch Trelleborg-ZulassungDatum: 26.09.05 Zeit: 12:17:36 Zeit;Kraft;Pressung;Weg;Dehnung[s];[kN];[N/mm**2];[mm];[mm]0.02; -0.03; -0.00; -0.00; 27.99;0.04; -0.02; -0.00; -0.01; 27.99;0.06; 0.00; 0.00; -0.01; 0.00;0.01; -0.01; -0.00; -0.01; 0.00;0.51; 0.01; 0.00; 0.31; 0.33;1.01; 0.01; 0.00; 0.80; 0.82; ...; ...; ...; ...; ...; ...; ...; ...; ...; ...;

Abbildung 2-3 Prüfdatei eines Druckversuches

Es besteht die Möglichkeit, den Inhalt und die Form der Prüfdatei (Abbildung 2-3) über

den Prüfcomputer zu konfigurieren. Dazu wird eine so genannte Drucksteuerdatei

benutzt. Innerhalb dieser Drucksteuerdatei sind bestimmte Drucksteuerbefehle

angegeben, die vom Prüfcomputer des Prüfstandes erkannt und verarbeitet werden

können. Ein Standardbeispiel für eine solche Drucksteuerdatei zeigt Abbildung 2-4.

$AS_KOPF Druckversuch Trelleborg-ZulassungDatum: #1 Zeit: #2 Zeit;Kraft;Pressung;Weg;Dehnung[s];[KN];[N/mm**2];[mm];[mm]

$AS_ERGZ c:\pm\Dat\trell\trell.dat

#3;#4;#5;#6;#7

$DR_VARS1 10000 0 0 0 0.0 0 ; aktuelles Datum 2 10010 0 0 0 0.0 0 ; aktuelle Uhrzeit 3 11030 7 2 0 1.0 0 ; Versuchszeit 4 11000 7 2 0 -0.001 0 ; Kraft 0:N, 1:N/mmý65 11000 7 2 0 -1.0 1 ; Kraft 0:N, 1:N/mmý6 11010 7 2 0 -1.0 0 ; Weg 0:mm, 1:%E(s)7 11020 7 2 0 -1.0 0 ; Dehnung

Abbildung 2-4 Drucksteuerdatei für einen Druckversuch

9


Die Befehle, die der Prüfcomputer verarbeiten kann, werden durch ein $ Zeichen

eingeleitet. Im gezeigten Beispiel definiert $AS_KOPF den späteren Kopfbereich der

Prüfdatei. Alle in Folge dieses Befehles geschriebenen Wörter werden in die Prüfdatei

übernommen. Wie aus Abbildung 2-4 zu erkennen ist, sind das die Angaben, die den

Versuch beschreiben. Diese sind beliebig anpassbar und werden an den Anfang der

Prüfdatei geschrieben. Damit ist man der Lage, die jeweilige Prüfdatei

auszukommentieren, um sie später einem Versuch zuordnen zu können. Wird ein neuer

Drucksteuerbefehl erkannt, endet der Kopfbereich. Im abgebildeten Beispiel Abbildung

2-4 ist das der Befehl $AS_ERGZ. Er beschreibt den Pfad, wohin die Prüfdatei auf dem

angeschlossenen Prüfcomputer gespeichert wird. Als zweites Werkzeug zur

Formatierung der Prüfdatei stehen die so genannten Platzhalter zur Verfügung. Das

sind Variablen, die beliebig definiert werden können. Diese werden an den Stellen

platziert, an denen der Prüfcomputer aktuelle Messwerte des Versuches einfügen soll.

Sie werden mit einem # (ASCII Code 043) Zeichen gekennzeichnet. Welche Messwerte

sich hinter den Platzhaltern verbergen, wird am Ende der Datei definiert. Die Definition

der Platzhalter wird über den Befehls $AS_ERGZ eingeleitet. Im abgebildeten Beispiel

(Abbildung 2-4) sei auf den Platzhalter #3 verwiesen, der die aktuelle Versuchszeit

beinhaltet. An der Position des Platzhalters #3 wird innerhalb der Prüfdatei die aktuelle

Versuchszeit eingefügt. Mit Hilfe der Platzhalter ist man in der Lage, sämtliche zu

einem bestimmten Versuch benötigten Messwerte zu definieren sowie deren Position

innerhalb der Prüfdatei festzulegen. Auf die genaue Aufschlüsselung der Codierung der

Platzhalter wird an dieser Stelle verzichtet und auf die Prüfstandeigene Dokumentation

verwiesen, die am Verkehrsbaulehrstuhl vorliegt. Im Beispiel (Abbildung 2-4) wurden

hinter den Zuweisungen Kommentarzeilen eingefügt, welche die Belegung der

Platzhalter beschreiben.

2.1.2 Weiterverarbeitung der Prüfdaten

Nach Beendigung des Versuchs müssen die Ergebnisse ausgewertet und protokolliert

werden. Dazu werden momentan MS-Excel und MS-Word eingesetzt. Bei der Vielzahl

der Versuche ist es jedoch schwierig, einen Überblick über die Gesamtheit der

Prüfvorgänge zu erhalten. Um die Verwaltung der gesamten Prüfabläufe zu

10


vereinfachen, wurde in einer Studienarbeit [1] eine Access Datenbank entwickelt und

mittels einer Visual-Basic-Clientanwendung optimiert. Diese Datenbank steht

serverseitig allen Mitarbeitern zur Verfügung und speichert alle Daten, die den Versuch

beschreiben, ab - nicht aber die eigentlichen Prüfdaten. Letztere werden in die

Datenbank importiert, und anschließend außerhalb der Datenbank gespeichert. Die

Speicherung wird in einem speziellen Visual-Basic Binärformat1 vorgenommen. Dieses

Binärformat wird von der Visual-Basic-Anwendung erzeugt und kann ausschließlich

von dieser wiederhergestellt werden. Der Hintergrund der externen, binären

Speicherung der Messdaten ist, die Datenbank nicht unnötig aufzublähen, da die

Prüfdateien teilweise sehr groß werden können. Außerdem wird mit Hilfe des

Binärformates eine erhebliche Speicherplatzeinsparung gegenüber dem Textformat der

originalen Prüfdatei erzielt. In der Datenbank wird jedem Versuch ein Link auf die

zugehörige, extern gespeicherte Binärdatei zugeordnet. Man ist mittels der Visual-

Basic-Anwendung in der Lage, nach Auswahl eines Versuches aus der Datenbank, die

zugehörige Binärdatei wiederherzustellen. Nach dem Import der Binärdatei liegen die

Messdaten in tabellarischer Form innerhalb der MS-Access Datenbank vor.

In einer weiteren Studienarbeit [2] wurde eine Java Applikation entwickelt, welche die

Darstellung der Messdaten ermöglicht. Dazu werden die wiederhergestellten Prüfdaten

aus der MS-Access Datenbank gelesen und in Koordinatensystemen dargestellt. Mit der

Java-Anwendung kann die Art der grafischen Darstellung komfortabel angepasst

werden. Weiterhin sind Funktionalitäten zum Drucken und Speichern der visualisierten

Messreihen vorhanden.

1 Das Binärformat ist ein Format in dem der Computer Daten speichern kann. Es kann alle Zeichen des Zeichensatzes enthalten, inkl. der Steuerzeichen. Im meisten Fällen ist der interne Aufbau der Formate nicht bekannt, d.h. die Formate können ausschließlich mit der Software mit welcher sie erzeugt wurden gelesen werden.

11


2.2 Vorhandene Lösungen

Die Evaluierung der beiden Arbeiten lieferte Ansatzpunkte für Verbesserungen.

Nachfolgend werden Probleme erläutert, die mit der momentan genutzten MS-Access

Datenbank sowie der Java-Applikation auftreten

2.2.1 Datenbank

Ein Hauptproblem der vorhandenen Datenbanklösung ergibt sich aus der Tatsache, dass

den Versuchen nur eine Prüfdatei zugeordnet werden kann. Einige Prüfungen weisen

aber mehrere Prüfdateien auf. Bei einem Schubversuch wird der Probekörper

beispielsweise in vertikaler und horizontaler Richtung belastet. Am Prüfstand ist

deswegen ein horizontaler bzw. ein vertikaler Messsensor angebracht. Jeder dieser

Sensoren liefert eine Prüfdatei. Somit müssen dem Versuch mehrere Messreihen

zugeordnet werden können. Diese Möglichkeit besteht mit der aktuellen Version der

Datenbank nicht. Weiterhin können an einem Versuch auch mehrere verschiedene

Probekörper beteiligt sein. Die gleichzeitige Zuordnung unterschiedlicher Probekörper

zu einem Versuch wird ebenfalls nicht unterstützt. Ferner entspricht die Bedienung der

vorhandenen Versuchsdatenbank mittels der Visual-Basic-Anwendung nicht der

vorgesehenen Arbeitsweise. Im Augenblick ist die Erfassung der Probekörper innerhalb

der Datenbank an die gleichzeitige Erfassung eines Versuches gebunden. Das ist

deshalb ungünstig, da die Probekörper bei Lieferung zuerst erfasst, eindeutig

gekennzeichnet und unabhängig von den Versuchen in die Datenbank eingepflegt

werden sollen. Weiterhin stellt sich der Import der Messdaten ungünstig dar, weil dieser

nur eine statische Anzahl von Messwertspalten innerhalb einer Prüfdatei zulässt

(Prüfdatei s. Abbildung 2-3). Die Prüfdateien können aber bedingt durch die Art der

Versuche unterschiedlich viele Messwertspalten aufweisen. So kann es beispielsweise

bei älteren Prüfdateien vorkommen, dass diese 3 oder 4 Messwertspalten enthalten. Da

der Importfilter der Visual-Basic-Anwendung 5 Spalten erwartet, ist das Einlesen dieser

Dateien nicht möglich Aus diesem Grund ist es sinnvoll, den Import dieser Prüfdaten

dynamisch zu gestalten. Weiterhin muss der Gesamtablauf einer Versuchsaufnahme

effizienter gestaltet werden. Es ist sinnvoll, die Daten zum Versuch, die in der

12


Datenbank gespeichert werden sollen, aus der Prüfdatei heraus zu erkennen und

einzulesen. Ebenso ist zu überlegen, ob das Speichern der Prüfdaten in binärer Form

sinnvoll ist, da es den Nachteil mit sich bringt, dass die so archivierten Daten nur von

der Visual-Basic-Anwendung eingelesen werden können. Die aufgezeigten Probleme

traten bei der Nutzung der Datenbank auf und sind im Rahmen der Diplomarbeit

„Druckstauchungsverhalten bewehrter Elastomerlager“ von Sven Georgi [10], im

Kapitel 4 beschrieben.

2.2.2 Visualisierung

Nach der Aufnahme des Versuches in die Datenbank müssen die aufgezeichneten

Messwerte analysiert werden. Um eine effektive Analyse vornehmen zu können, ist eine

grafische Darstellung der Messwerte sinnvoll. Die Visualisierung der Messdaten ist

jedoch nicht unproblematisch, da die Datenmengen der Prüfdateien teilweise sehr

umfangreich sind. So kann mit MS-Excel, mit dessen Hilfe die momentane Auswertung

der Prüfdaten realisiert wird, nur eine begrenzte Anzahl von Messreihenzeilen

eingelesen werden. Bei größeren Prüfdateien stellt sich das als sehr ungünstig dar, weil

man diese Dateien aufteilen muss und somit nur Abschnitte der Messreihen betrachten

kann. Dadurch erhält man keinen Gesamtüberblick über den Kurvenverlauf der

Messwerte eines Versuches. Das wäre jedoch von großem Vorteil, weil man dadurch

schneller in der Lage wäre, eventuell interessante Stellen der Kurve zu lokalisieren.

Mit der in einer Studienarbeit [2] entstandenen Java-Applikation können die Messdaten

ebenfalls visualisiert werden. Dazu wird die Java-Applikation aus der MS-Access

Anwendung heraus gestartet und die innerhalb von MS-Access vorliegenden,

importierten Prüfdaten können grafisch dargestellt werden. Zur Darstellung werden aus

den Prüfdaten erzeugte Kurvenverläufe genutzt, die innerhalb von Koordinatensystemen

angezeigt werden.

Bei der Visualisierung mittels der Java-Anwendung treten jedoch sehr schnell

Performanceprobleme auf. Dies ist bedingt durch die sehr großen Datenmengen die

vom Prüfstand geliefert werden. Als Beispiel sei erwähnt, dass die Prüfmaschine in

einer Sekunde bis zu 100-mal die Zeit und damit die dazugehörigen Messwerte

13


aufzeichnen kann. Wenn man bedenkt, dass ein Druckversuch bis zu einer Stunde

andauert, würde das für diesen Fall 360.000 Messzeilen bzw. Wertepaare zur Folge

haben. Diese Menge von Wertepaaren in Form einer Kurve zu visualisieren, ist mit der

Java-Applikation oder MS-Excel nicht möglich. Innerhalb von MS-Excel stehen dem

Anwender nur maximal 65536 Zeilen zur Aufnahme von Messwerten zur Verfügung. In

der Java-Applikation führen Wertepaarmengen von dieser Größenordnung zu einem

derartigen Performanceverlust, dass die Anwendung nicht mehr bedienbar ist.

Momentan wird dieses Problem von der vorhandenen Java-Applikation gelöst, indem

sie nicht jeden Punkt der Messreihe darstellt, sondern je nach Anzahl der Messreihen,

beispielsweise nur jeden 10. Messpunkt. Das hat den Nachteil, dass eventuelle

Ausreißerpunkte der Kurve nicht angezeigt werden oder sogar Maxima und Minima

entfallen. Damit würde die erzeugt Kurve nicht den tatsächlichen Verlauf über die

Messwertreihen kennzeichnen. Deshalb wird untersucht, ob mit geeigneten

Algorithmen ein Verfahren entwickelt werden kann, mit dem die Kurve „ausdünnt“,

d.h. die Punktmenge reduziert werden kann, ohne Ausreißerpunkte oder markante

Punkte wie z. B. Wendepunkte, Maxima oder Minima einer Kurve zu verlieren.

14

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Lösungskonzept

3 Lösungskonzept

Ausgehend von den in Kapitel 2.2 beschriebenen Nachteilen, ergibt sich ein neues

Anforderungsprofil an die Datenbank sowie die zu entwickelnde Applikation. Es ist ein

Datenbankschema zu entwerfen, welches die vorhandenen Mängel beseitigt und eine

flexiblere Nutzung der Datenbank zulässt. Dazu wird in einem ersten Schritt (Kapitel

3.1) der Prüfstand untersucht. Hintergrund der Untersuchung ist, die in der Prüfdatei

(Abbildung 2-3 Prüfdatei eines Druckversuches) enthaltenen Daten so zu kennzeichnen,

dass eine Applikation in der Lage ist, die Informationen zu den Versuchen aus den

Prüfdateien einzulesen. Dadurch wird es möglich, eine Automatisierung bei der

Versuchsaufnahme zu erreichen. Um jedoch sämtliche beschreibenden Parameter zu

den Versuchen speichern zu können, muss ein neu strukturiertes Datenbankmodell

angelegt werden. Ausgerichtet auf dieses Modell soll eine Applikation entstehen, die

Funktionalitäten wie Hinzufügen, Löschen oder Anzeigen von Datensätzen bereitstellt.

Vor allem die grafische Anzeige der Messdaten soll optimiert werden.

3.1 Modifikationen an der Prüfdatei

Wie unter Kapitel 2.1.1 beschriebenen, erfolgt die Speicherung der Prüfdaten innerhalb

der Prüfdatei. Deren Struktur wird nach einem Schema, das innerhalb der

Drucksteuerdatei definiert ist, festgelegt. Sollen Informationen innerhalb dieser

Prüfdatei kenntlich gemacht werden, gibt es die Variante sie mit einem eindeutigen

Schlüsselwort zu beschreiben. Die zu entwickelnde Java-Applikation soll in der Lage

sein, solch ein Schlüsselwort zu erkennen und die so gekennzeichnete Information

auszulesen. Dazu muss das Schlüsselwort vor die jeweilige Information innerhalb der

Prüfdatei gestellt werden, wodurch der Inhalt der nachfolgenden Zeichenkette

beschrieben wird. Beim Design der Schlüsselwörter wurde darauf geachtet, dass diese

„gut lesbar“ sind, d.h. die Namensgebung der Schlüsselwörter ist orientiert an der

Bedeutung der jeweils gekennzeichneten Information. Die Struktur der Schlüsselwörter

wurde an die XML Syntax (Extensible Markup Language) angelehnt. Das XML

ähnliche Layout ist frei gewählt und wurde mit dem Hintergedanken eingeführt, dass

eventuell andere Applikationen eine bereits „bekannte“ gut lesbare Datenstruktur

15


vorfinden und verarbeiten können. Tabelle 1 enthält die zu diesem Zweck eingeführten

Schlüsselwörter.

Information zum Versuch

innerhalb der Prüfdatei

Eingeführte Schlüsselwörter zur

Beschreibung der Information

Zeilenanfang Zeilenende

Versuchsart <V_ART> </V_ART>

Kurzbezeichnung des Prüfers <V_PRUEFER> </V_PRUEFER>

Datum des Versuches <V_DATUM> </V_DATUM>

Zeit des Versuches <V_ZEIT> </V_ZEIT>

Versuchsanlass <V_ANLASS> </V_ANLASS>

Interne Nummer des Probe

körpers <V_PK_INR> </V_PK_INR>

Kurzbezeichnung der Messreihe <V_DATENSATZ_KB> </V_DATENSATZ_KB>

Bezeichnung der Prüfmaschine <V_PM> </V_PM>

Bezeichnung der Spaltennamen <V_SPALTEN> </V_SPALTEN>

Bezeichnung der Einheiten <V_EINHEITEN> </V_EINHEITEN>

Die eigentlichen Messdaten

des Versuches (Prüfdaten) <PD> </PD>

Tabelle 1 Übersicht über die eingeführten Schlüsselwörter

Um die Schlüsselwörter innerhalb der Prüfdatei unterzubringen, müssen sie in die

Drucksteuerdatei (Abbildung 2-4 Drucksteuerdatei vor der Modifizierung) eingefügt

werden, die das Aussehen der später erzeugten Prüfdatei festlegt. Über die

Drucksteuerdatei werden die Schlüsselwörter bei der Versuchsdurchführung in die

Prüfdatei geschrieben. Nach einigen Variationen bei der Anordnung der

Schlüsselwörter innerhalb der Drucksteuerdatei, hat sich der in Abbildung 3-1 gezeigte

modifizierte Aufbau bewährt. Die eingefügten Wörter sind blau hervorgehoben, die

Drucksteuerbefehle sind schwarz und fettgedruckt. (Im gezeigten Beispiel wurden nicht

alle definierten Schlüsselwörter verwendet.)

16


$AS_KOPF<V_ART>;Druckversuch;</V_ART><V_ANLASS>;Trelleborg-Zulassung;<V_ANLASS><V_DATUM>;Datum: #1;</V_DATUM><V_ZEIT>;Zeit: #2;</V_ZEIT><V_SPALTEN>;Zeit;Kraft;Pressung;Weg;Dehnung;</V_SPALTEN><V_EINHEITEN>;[s];[kN];[N/mm**2];[mm];[mm];</V_EINHEITEN>$AS_ERGZ c:\pm\Dat\trell\trell.dat<PD>;#3;#4;#5;#6;#7;</PD>

$DR_VARS1 10000 0 0 0 0.0 0 ; aktuelles Datum 2 10010 0 0 0 0.0 0 ; aktuelle Uhrzeit 3 11030 7 2 0 1.0 0 ; Versuchszeit 4 11000 7 2 0 -0.001 0 ; Kraft 0:N, 1:N/mmý65 11000 7 2 0 -1.0 1 ; Kraft 0:N, 1:N/mmý6 11010 7 2 0 -1.0 0 ; Weg 0:mm, 1:%E(s)7 11020 7 2 0 -1.0 0 ; Dehnung

Abbildung 3-1 Modifizierte Drucksteuerdatei

Es ist darauf zu achten, dass nach jedem einleitenden Schlüsselwort sowie vor jedem

Endschlüsselwort ein Semikolonzeichen einzufügen ist. Weiterhin müssen die einzelnen

Spaltennamen und Einheiten, die hinter den Schlüsselwörtern <V_SPALTEN > und

<V_EINHEITEN> angegeben werden sowie die Probekörpernummern hinter dem

Schlüsselwort <V_PK_INR> durch Semikolonzeichen getrennt werden. Das Einfügen

der Semikolonzeichen ist erforderlich, um den Import in MS-Excel zu erleichtern, da die

Auswertungen und Analysen noch vorrangig mit diesem System vorgenommen werden.

Ebenso benutzt die später vorgestellte Java-Klasse das Semikolon als Trennzeichen. Es

muss darauf geachtet werden, die versuchsbeschreibenden Informationen sowie die

Schlüsselwörter, innerhalb des Kopfbereiches der Drucksteuerdatei anzugeben, der von

dem Steuerbefehl $AS_KOPF eingeleitet wird. Wird nun bei der Versuchsdurchführung

die abgeänderte Drucksteuerdatei (Abbildung 3-1) verwendet, erzeugt der Prüfcomputer

des Prüfstandes die in Abbildung 3-2 gezeigte veränderte Prüfdatei. Der Unterschied zur

bisherigen Prüfdatei ist, dass innerhalb der neu erzeugten Prüfdatei die Informationen

zum Versuch sowie den Prüfdaten, mit den entsprechenden Schlüsselwörtern

gekennzeichnet sind. Durch die vorgenommenen Veränderungen an der

17


Drucksteuerdatei, ist innerhalb der

beschreibende Struktur vorhanden.

Prüfdatei eine XML ähnliche, den Inhalt

<V_ART>;Druckversuch;<V_ART><V_ANLASS>;Trelleborg-Zulassung;</V_ANLASS><V_DATUM>;Datum: 26.09.05;</V_DATUM><V_ZEIT>;Zeit: 12:17:36;</V_ZEIT><V_SPALTEN>;Zeit;Kraft;Pressung;Weg;Dehnung;</SPALTEN><V_EINHEITEN>;[s];[kN];[N/mm**2];[mm];[mm];</V_EINHEITEN><PD>; 0.02; -0.03; -0.00; -0.00; 27.99;</PD><PD>; 0.04; -0.02; -0.00; -0.01; 27.99;</PD><PD>; 0.06; 0.00; 0.00; -0.01; 0.00;</PD><PD>; 0.01; -0.01; -0.00; -0.01; 0.00;</PD><PD>; 0.51; 0.01; 0.00; 0.31; 0.33;</PD><PD>; 1.01; 0.01; 0.00; 0.80; 0.82;</PD><PD>; ...; ...; ...; ...; ...;</PD><PD>; ...; ...; ...; ...; ...;</PD><PD>; ...; ...; ...; ...; ...;</PD><PD>; ...; ...; ...; ...; ...;</PD><PD>; 10.01; 4.01; 1.00; 0.80; 0.82;</PD><PD>; 11.01; 5.01; 2.00; 0.80; 0.82;</PD><PD>; 12.01; 6.01; 3.00; 0.80; 0.82;</PD>

Abbildung 3-2 Neue Prüfdatei

Für die neu strukturierte Prüfdatei ist es wesentlich einfacher, einen Importfilter oder

Parser1 zu entwickeln, welcher die Prüfdaten aus der Datei herauslesen kann. Durch die

gute „Lesbarkeit“ der Befehle, werden die Bedeutung und der Inhalt der umschlossenen

Information sofort klar.

1 Parser (deutsch „analysieren“) bezeichnet im Allgemeinen ein Programm, das in der Lage ist zu entscheiden ob eine Zeichenkette(in diesem Fall das Schlüsselwort) zu einer bestimmten Sprachsyntax gehört.

18


3.2 Datenbankentwurf

Um den Anforderungen gerecht zu werden, die sich aus der Speicherung der

Prüfabläufe innerhalb einer Datenbank ergeben, ist es erforderlich ein neues

Datenbankmodell zu entwickeln. Datenbankentwürfe werden in der Regel unter zu

Hilfenahme des Entity-Relationship-Modells erstellt. Dieses Modell stellt einen

Ausschnitt der realen Welt mit Hilfe eines grafischen Schemas dar, das mittels eines

relationalen DBMS (Datenbankmanagementsystem) umgesetzt werden kann.

3.2.1 Entity Relationship Modell

Das Entity–Relationship-Modell oder auch ER-Modell oder ERM, wurde erstmals von

Peter Chen, in seiner Veröffentlichung „The Entity Relationship Model“ vorgestellt. Es

wird in einer ersten konzeptionellen Phase als Basis für das Design einer Datenbank

verwendet. Dabei sind die Begriffe Entität und Relationship folgendermaßen definiert:

Eine Entität repräsentiert Objekte der Wirklichkeit, während ein Relationship

(Beziehung) den Zusammenhang zwischen zwei Entitäten (Objekten) beschreibt. Eine

Entität besitzt wiederum Attribute, welche die Eigenschaften des Objektes

repräsentieren. Abbildung 3-3 zeigt die die Modellierungssyntax des ER-Modells.

Abbildung 3-3 Modellierungssyntax des ER-Modells

19


Des Weiteren wird durch Kardialitäten die Anzahl der an einer Beziehung beteiligten

Entitäten (Objekte) beschrieben. Diese werden an der Beziehung angegeben. Bei den

Kardialitäten definiert man drei Abstufungen:

• 1:1

Bei einer 1:1 Beziehung wird einer Entität genau eine andere Entität zugeordnet. (Ein häufig genanntes Beispiel in der Literatur hierzu ist „Ein Ehepartner ist mit genau einem anderen Ehepartner verheiratet“; in Deutschland)

• 1:N ; N:1

Bei einer 1:N Entität werden genau einer Entität auf der einen Seite, eine oder mehrere Entitäten auf der anderen Seite zugeordnet. Dazu ein Beispiel in Anlehnung an die Versuchsdatenbank. Ein Prüfer kann einen oder mehrere Versuche durchführen. Jeder Versuch jedoch wird von genau einem Prüfer durchgeführt. (Prüfer 1:N Versuch)

• N:M

Bei diesem Beziehungstyp können auf beiden Seiten beliebig viele Entitäten stehen. Beispiel in Anlehnung an die Versuchsdatenbank: Ein Probekörper kann an mehreren Versuchen beteiligt sein. An einem Versuch sind mindestens einer oder aber mehrere Probekörper beteiligt. (Versuch N:M Probekörpern)

Diese verschieden Beziehungstypen können in relationalen Datenbanksystem umgesetzt

werden. In dieser Arbeit wird dazu aufgrund der unter Kapitel 4.1 genannten Gründe

MS-Access von Microsoft verwendet.

Um einen noch tieferen Einblick in die Problematik und den Aufbau des Entity–

Relationship–Modells zu erhalten, sei auf weiterführende Literatur verwiesen [8].

20


3.2.2 Konzept der Versuchsdatenbank

Als erster Schritt bei der Konzepterstellung wurde eine Anforderungsanalyse für die zu

entwerfende Datenbank durchgeführt. Bezogen auf die erarbeiteten Anforderungen

wurde ein komplett neues Datenbankschema entworfen. Diese neuen Anforderungen an

die Datenbank ergaben sich aus den unter Kapitel 2.2 beschriebenen Mängeln der

vorhandenen Datenbanklösung. Zunächst wurde mit Hilfe des ER–Modell Entwurfes

die Problematik eines Versuchs schematisch abgebildet. Dabei werden die Beziehungen

zwischen den einzelnen Tabellen (Entitäten) untereinander deutlich gemacht. Abbildung

3-4 zeigt das neu entworfene ER-Modell der Versuchsdatenbank. Auf die Zuordnung

von Attributen soll bei folgendem Schema verzichtet werden, um die Übersichtlichkeit

zu gewährleisten. Die Attribute der einzelnen Tabellen werden später unter Kapitel 4.2

vorgestellt.

Abbildung 3-4 Modellentwurf der Versuchsdatenbank

Anhand der Relationen zwischen Prüfer-Versuch und Versuch-Messreihe soll

beispielhaft verdeutlicht werden, wie diese zu lesen sind (Tabelle 2 Seite 22):

21


Richtung Versuch nach Prüfer Richtung Prüfer nach Versuch

Jeder Versuch wird von genau

einem Prüfer geleitet.

Jeder Prüfer leitet einen

mehrere Versuche.

oder

Richtung Versuch nach Messreihe Richtung Messreihe nach Versuch

Jeder Versuch erzeugt mindestens

eine oder aber beliebig viele

Messreihen.

Jede Messreihe gehört zu

einem Versuch

genau

Tabelle 2 Lesen der Relationen

Mit Hilfe des abgebildeten ER - Modells ist man in der Lage, die Datenbank zu

implementieren, unabhängig davon auf welches relationale DBMS die Wahl fällt. Für

die Implementierung der Datenbank innerhalb der meisten relationalen

Datenbanksysteme, kommt die standardisierte Sprache SQL (Structured Query

Language) zum Einsatz.

3.2.3 SQL

Unter diesem Punkt folgt ein kurzer geschichtlicher Abriss, sowie eine grobe

Beschreibung der Programmiersprache SQL, ohne die Syntax genau zu erläutern. Es soll

dem Leser ein Eindruck verschafft werden, was SQL beinhaltet, und zu leisten in der

Lage ist.

SQL gehört zu der Gruppe der deklarativen1 Programmiersprachen. Sie wurde in den

siebziger Jahren von IBM entwickelt. Grundlage dazu bildete der Artikel „A Relational

Model of Data for Large Shared Data Banks“ von Edgar F. Codd. Aufbauend auf

diesem Werk, brachte IBM 1976 „SEQUEL /2“ (Structured English Query Language)

1 So bezeichnet man Programmiersprachen, die auf der Basis logischer Kalküle aufgebaut sind. (z. B. SQL, HTML) Im Gegensatz dazu, existieren imperative und objektorientierte Sprachen, wie z.B. C, C++ und Java.

22


heraus. Dieses Projekt wurde aber aus rechtlichen Gründen in „SQL” umbenannt. Im

Jahre 1986 wurde erstmals eine Art Standard für die Programmiersprache SQL definiert.

Infolge dessen wurde 1992 der SQL-92 Standard (SQL2) erschaffen. In ihm hielten

zahlreiche Erweiterungen und Überarbeitungen Einzug. Die meisten aktuellen

Datenbanksysteme haben den SQL-92 Standard implementiert und halten sich zum

größten Teil an diesen. Weiterführend wurde 1999 mit SQL3 eine weitere Version

definiert, welche die Einführung der Objektorientierung in SQL brachte. Diese Version

stellte bei der Entwicklung der Programmiersprache einen großen Schritt nach vorn dar.

Jedoch beinhaltete sie, neben vielen Verbesserungen auch eine Reihe von

Widersprüchen und Fehlern. Diese zu korrigieren und weitere Features hinzuzufügen,

waren die Gründe, die zur Entwicklung des mittlerweile fünften Standards dieser

Sprache führten: SQL2003. Der SQL99 und SQL2003 Standard sind in kommerziellen

relationalen Datenbanksystemen noch nicht sehr weit verbreitet.

Die Sprache SQL gliedert sich in vier separate Schichten, die hier kurz vorgestellt

werden sollen:

• Data Query Language (DQL)

SELECT Befehl – dient zum Erstellen von Abfragen in einer Datenbank und liefert eine Ergebnismenge zurück, die den angegebenen Bedingungen genügt.

• Data Control Language (DCL)

GRANT, REVOKE – dienen zur Definition von Rechten innerhalb der Datenbank

• Data Manipulation Language (DML)

INSERT, UPDATE, DELETE – dienen zur Datenmanipulation innerhalb der Datenbank. Mit Hilfe dieser Befehle können Daten aktualisiert, eingefügt oder gelöscht werden.

23


• Data Definition Language (DDL)

CREATE, ALTER, DROP – sind Befehle zur Datendefinition. Mit Hilfe dieser Befehle können Tabellen, Referenzen und Attribute erstellt und definiert werden.

Mit Hilfe der hier vorgestellten SQL Programmiersprache ist es möglich Datenbanken

zu implementieren. Das ER-Modell spielt dabei eine bedeutende Rolle, da es

gewissermaßen als Vorlage für den Entwurf dient, den es innerhalb eines DBMS

umzusetzen gilt. Die meisten Datenbankhersteller erweitern die Grundfunktionalität

von SQL durch eigene Befehlsdefinitionen, jedoch orientieren sich alle weitestgehend

am SQL-92 Standard. DBMS, wie z. B. MS-Access, bieten dem Nutzer darüber hinaus

grafische Oberflächen und Assistenten an, um die Erstellung von Tabellen, Attributen,

Beziehungen und Abfragen zu erleichtern.

3.2.4 ODBC

ODBC steht für „Open-Database-Connectivity“ oder eingedeutscht für „Offene

Datenbank-Verbindungsfähigkeit“ und wurde von Microsoft 1992, unter Mitarbeit von

verschiedenen Datenbanksystemherstellern definiert. Diese Schnittstelle nutzt SQL als

Datenbanksprache und ermöglicht den Zugriff auf Daten innerhalb eines

Datenbankmanagementsystems. Dazu wird dem Programmierer eine API (Application

Program Interface) zur Verfügung gestellt, die ihm ermöglicht, Applikationen

unabhängig vom benutzten DBMS zu implementieren. Die Abbildung 3-5 auf Seite 25

erläutert schematisch den Aufbau der ODBC-Schnittstelle.

Die verschiedenen Applikationen können über den ODBC-Treiber-Manager, der fester

Bestandteil des Betriebssystems Windows ist, Funktionen eines ODBC-Treibers

anfordern. Dieser Treiber-Manager verwaltet die zu den verschiedenen DBMS

gehörenden ODBC-Treiber. In der Regel ist für jedes Datenbanksystem ein Treiber

vorhanden, da dieser sehr häufig von den Herstellern zur Verfügung gestellt wird.

24


Abbildung 3-5 ODBC Treiberstruktur

Der ODBC-Treiber-Managers fungiert als Übersetzer zwischen den Applikationen und

dem verwendeten DBMS. Dabei werden die, über die API Schnittstelle des Treiber-

Managers angeforderten SQL Anfragen der Applikationen, an den entsprechenden

ODBC-Treiber des DBMS weitergeleitet. Dieser „übersetzt“ diese Befehle für das

jeweilige DBMS. Er organisiert dabei z.B. die Ausführung der unterschiedlichen

„Befehlsdialekte“ von SQL, welche die verschiedenen DBMS aufweisen. Die

Vorgehensweise beim Zugriff auf Daten ist folgende: Die Applikation baut mit Hilfe

des entsprechenden Treibers eine Verbindung zur Datenbank auf. Danach wird eine

Anfrage auf der Datenbank ausgeführt und die Ergebnisse verarbeitet. Schließlich wird

die Datenbankverbindung wieder geschlossen. Dabei ist es irrelevant ob der Zugriff auf

die Datenquelle lokal oder im Netzwerk erfolgt.

Die ODBC-Schnittstelle ist heute in der Windows-Welt weit verbreitet und hat sich dort

als ein Standard zum Zugriff auf Datenbanken etabliert. Darüber hinaus wurde ODBC

bereits auf andere Plattformen übertragen. Z.B. existieren Portierungen für Unix

25


Plattformen sowie für Linux- und Apple-Macintosh-Systeme. Diese werden nicht von

Microsoft erstellt, sondern von den Herstellern der Betriebssysteme selbst übernommen.

26


3.3 Vorbetrachtung zur Visualisierung der Prüfdaten

3.3.1 Charakteristik der zu visualisierenden Kurven

Ausgehend von den Performanceproblemen (s. Kapitel 2.2.2), welche die erste Version

des Viewer-Tools bei der Darstellung der Prüfdaten mit sich brachte, wird zunächst

untersucht, inwieweit die Punktmenge der gesamten anzuzeigenden Kurve verringert

werden kann, ohne die Grundstruktur der Kurve zu verlieren. Dazu wurden aus

verschiedenen Versuchen Kurven erzeugt und untersucht. Beispielhaft wird anhand

eines Druckversuchs und der sich daraus ergebenden Kraft-Zeit-Kurve, die

Charakteristik der Kurvenverläufe erörtert. Die Gesamtdauer des im folgenden Beispiel

gezeigten Versuchs belief sich auf rund 400s. Ausgehend von der Tatsache, dass pro

Sekunde 100 Messwerte durch den Prüfcomputer in die Prüfdatei geschrieben werden,

ergibt sich für den gesamten Versuch eine anzuzeigende Punktzahl von 40.000

Messwerten. Abbildung 3-6 Kurvencharakteristik zeigt den Kraftverlauf über die Dauer

eines Druckversuches, sowie einen Teilbereich Kurve.

Abbildung 3-6 Kurvencharakteristik

Im oberen Diagramm ist der Gesamtüberblick über die Kurve dargestellt, im unteren

Diagramm der Kurvenbereich von 80s-81s. In diesem Kurvenausschnitt ist kein

regelmäßiger Verlauf der Kurve festzustellen. Die Kraft wird zwar mit ansteigender

27


Zeit größer, jedoch geschieht dies unter starker unregelmäßiger Oszillation (lat.

oszillare – schaukeln) der Kurve.

Verschiebt man den Kurvenbereich zwischen 200s-201s, stellt sich folgendes

verändertes Bild des Kurvenverlaufes dar.

Abbildung 3-7 Kurvencharakteristik 1

Die Kurve hat die Form ähnlich einer Sinusfunktion angenommen. Es ist ein sehr

regelmäßiger und gleichmäßiger Verlauf der Kurve zu erkennen. Es treten also in den

verschiedenen Bereichen unterschiedliche Kurvencharakteristika auf.

Um die Darstellung der Gesamtansicht zu beschleunigen, muss die Punktmenge der

angezeigten Kurve verringert werden. Dabei ist zu beachten, dass die Grundform der

Kurve erhalten bleibt. Im Folgenden werden Wege aufgezeigt, die Kurve zu glätten

bzw. „auszudünnen“ und dadurch deren Darstellung zu optimieren.

3.3.2 Punktreduzierung mittels Anstiegsdifferenz

Als erstes wurde der Versuch unternommen über der Differenz von Anstiegen

benachbarter Punkte eine Verringerung der Punktanzahl zu erreichen. Abbildung 3-8

erläutert das Prinzip.

28


Abbildung 3-8 Anstiegsdifferenz; links P2 wird gezeichnet; rechts P2 wird nicht gezeichnet

P1 sei der letzte gezeichnete Punkt der Kurve. P2 ist der betrachtete Punkt, für den

entschieden werden soll ob er gezeichnet werden muss, und P3 ist der Nachfolgerpunkt

von P2. Zuerst wird der Anstieg der Geraden P1/P2 sowie der Anstieg der Geraden

P2/P3 berechnet. Die Berechnung erfolgt nach (1).

Δx m = (1) Δy

Danach wird der Betrag der Differenz der beiden Anstiege gebildet (2) und über diesen

Wert d entschieden, ob der aktuell betrachtete Punkt P2 gezeichnet werden muss oder

nicht.

d = m − m (2) 1 2

Ist der Betrag der Differenz der Anstiege m1 und m2 (d) ungleich null, so liegen die

Punkte P1, P2 und P3 nicht auf einer Geraden(Abbildung 3-8 links). In diesem Fall

muss der aktuell betrachtete Punkt P2 zur Darstellung der Kurve gezeichnet werden.

(P2 wird damit zum neuen „letzten gezeichneten Punkt der Kurve“). Wenn d gleich null

ist (Abbildung 3-8 rechts), liegen die Punkte P1, P2 und P3 auf einer Geraden. Punkt

P2 muss zur grafischen Darstellung der Geraden P1/P2/P3 nicht berücksichtigt werden.

(P1 bleibt „letzter gezeichneten Punkt“) Im nächsten Schritt wird P3 neuer betrachteter

Punkt. Von ihm ausgehend werden wieder die Anstiege zum letzten gezeichneten Punkt

29

0 1 2 3 4 5 0 1 2 3 4 5


P1 und seinem Nachfolgerpunkt ermittelt. Ist der Betrag der Anstiegsdifferenz d wieder

null, so entfällt P3 und der Nachfolger von P3 wird neuer betrachteter Punkt.

Über einen variabel einzustellenden Wert wird eine Fehlertoleranz f eingeführt. Wenn

der Betrag der Differenz der Anstiege d kleiner als der Wert der Fehlertoleranz f ist,

wird dieser Fall behandelt, als wäre die Differenz der Anstiege null und der betrachtete

Punkt entfällt zur Darstellung. Die Einführung der Fehlertoleranz bewirkt, dass bei

geringen Anstiegsdifferenzen, d. h. wenn die Punkte „fast“ auf einer Geraden liegen,

diese entfallen und nicht gezeichnet werden. Dadurch reduziert sich die Menge der

Punkte, die zur Darstellung der Kurve nötig sind. Dies wiederum führt zu einer

Beschleunigung der grafischen Darstellung, da weniger Punkte gezeichnet werden

müssen. Mit diesem Verfahren wird der originale Kurvenverlauf sehr gut angenähert.

Der Algorithmus wurde am Beispiel einer Sinuskurve mittels MS-Excel und einem

Visual-Basic Makro getestet.

5% Fehlertoleranz 25 % Fehlertoleranz

6 6

4 4

2 2

0 0 6 6

-2 -2

-4 -4

-6 -6

Abbildung 3-9 Punktreduzierung mittels Anstiegsverfahren

Abbildung 3-9 zeigt eine Sinuskurve in Form einer durchgehenden Linie im

Hintergrund. Diese Kurve besteht aus 500 Wertepaaren. Die Kreuze, die über die Kurve

gelegt wurden, beschreiben die Punktmenge der „ausgedünnten“ Kurve nach

Optimierung mittels des eben beschriebenen Verfahrens. Bei einer Fehlertoleranz von

5% (f=0,05 Einheiten) werden zur Darstellung der Kurve nur noch 313 Punkte benötigt

(Abbildung 3-9 linke Darstellung). Bei einer Toleranz von 25% (s. Abbildung 3-9

30


rechte Darstellung) sogar nur noch 121 Punkte. Wie aus Abbildung 3-9 zu erkennen ist,

werden die „fast“ geraden Stücke der Kurve sehr gut angenähert. In den Bereichen der

Maxima und der Minima der Kurve wird eine dichtere Punktmenge beibehalten, was

zur Darstellung dieser Kurvenbereiche notwendig ist. Eventuelle Ausreißerpunkte

bleiben bei der Anwendung dieser Methode erhalten.

Bei weiteren Betrachtungen stellte sich heraus, dass dieses Verfahren nur in den

Bereichen der Kurve gute Ergebnisse liefert, wo ein regelmäßiger, gleichmäßiger

Kurvenverlauf vorliegt (Abbildung 3-7, Seite 28). In den Kurvenbereichen mit starken

unregelmäßigen Oszillationen (Abbildung 3-6, Seite 27), bringt diese Optimierung

keine erhebliche Verminderung der Punktmenge mit sich. Bedingt durch die starken

Schwankungen der Kurve (Abbildung 3-6, Seite 27), wird der Betrag der Differenz der

betrachteten Anstiege d (Formel (2)) größer null, und damit werden die Punkte in

diesem Bereich gezeichnet. Die Definition einer Fehlertoleranz bringt keine

Verbesserungen, da d in diesen Kurvenbereichen für fast jeden betrachteten Punkt

relativ groß wird.

3.3.3 Punktreduzierung mittels Linienglättung

Eine weitere Möglichkeit die Punktmenge zu reduzieren ist ein Verfahren einzusetzen,

dass als Linienglättung bezeichnet wird. Die Linienglättung spielt in der Kartographie

oder innerhalb von GIS-Systemen (Geo - Informationssystem) eine große Rolle. Es gibt

verschiedene Vorgehensweisen um eine Linienglättung zu erreichen. Bei allen ist das

Hauptaugenmerk darauf gelegt die Linie „auszudünnen“, d.h. die charakteristischen

Punkte der Linie sollen erhalten bleiben, wobei überflüssige Punkte entfernt werden

können. Hier soll ein Verfahren zur Untersuchung von Punkten in unmittelbarer

Nachbarschaft betrachtet werden, das auch als Pfeilhöhenverfahren bezeichnet wird.

(Abbildung 3-10 zeigt den Ansatz)

31


Abbildung 3-10 Pfeilhöhenverfahren allgemein

Bei diesem Verfahren werden drei aufeinander folgende Punkte betrachtet. P1 ist der

zuletzt gezeichnete Punkt der Kurve, P2 der betrachtete Punkt der Kurve und P3 der

Nachfolger von P2. Zunächst wird die Geradengleichung der Geraden P1/P3

aufgestellt. Danach wird der Betrag des lotrechten Abstandes d von P2 zu der Geraden

P1/P3 berechnet. Die Bildung des Betrags ist nötig, da der betrachtete Punkt P2 auch

auf der anderen Seite der Gerade P1/P3 liegen könnte. Dieser Abstand d wird auch als

Pfeilhöhe bezeichnet. Ist der Abstand d größer als eine festgelegte Toleranz f, muss P2

gezeichnet werden, da er zu weit von der Geraden entfernt ist. Anderenfalls liegt der

Punkt P2 so nah an der Geraden P1/P3, das er entfallen kann, und es wird mit der

Betrachtung des nächsten Punktes fortgefahren. Dieser Algorithmus ermöglicht eine

sehr gute Dezimierung der Punktmenge der Kurve unter Beibehaltung der Grundform.

Die Formel zur Berechnung des Abstandes d wird über die Gleichung des Abstandes

eines Punktes zu einer Geraden, und der Gleichung der Geraden in Hessescher

Normalform hergeleitet.

0 = x ∗ cos( )α + y ∗ sin(α )− p (3)

In die Gleichung (3) der Geraden werden die Koordinaten von P1 x1 und y1 eingesetzt

und für α der Anstieg der Geraden P1/P3, welcher sich berechnet aus:

32


⎛ Δx ⎞α = arctan⎜⎜ ⎟⎟ (4)⎝ Δy ⎠

Wenn (3) nach p umgestellt wird und P1 und α eingesetzt wird ergibt sich:

( )+ y ∗ sin(α ) (5)p = x1 ∗ cos α 1

Für den Abstand d gilt somit:

d = x2 ∗ cos( )+ y2 *sin(α )− pα (6)

In (6) sind x2 und y2 die Koordinaten des Punktes P2, der Abstand zur Gerade P1/P3

hat.

Anhand von Abbildung 3-11 wird skizzenhaft die Vorgehensweise des Algorithmus

verdeutlicht.

Abbildung 3-11 Pfeilhöhenverfahren Beispiel

33


Es sei P1 der letzte gezeichnete Punkt der Kurve, P2 der betrachtete Punkt der Kurve

(für den eine Entscheidung getroffen werden soll ob er gezeichnet wird oder nicht) und

P3 sein Nachfolger. Im konkreten Beispiel auf Seite 33 Abbildung 3-11 arbeitet der

Algorithmus wie folgt:

Es wird ausgehend von P1 die Gerade zu P1/P3 gebildet. Danach wird festgestellt, dass

der Abstand von P2 zur Geraden P1/P3 größer als die festgelegte Toleranz ist und P2

muss gezeichnet werden. Im darauf folgenden Schritt ist P2 letzter gezeichneter Punkt

und es wird P3 betrachtet. Dazu wird die Gerade P2/P4 gebildet. Nun wird festgestellt,

dass der Abstand von P3 zur Geraden P2/P4 kleiner ist als die Toleranz. Daher entfällt

P3 (P2 bleibt letzter gezeichneter Punkt). Darauf folgend wird die Gerade P2/P5

gebildet und der Abstand von P4 zu P2/P5 überprüft. Dieser Abstand ist größer als die

Toleranz und P4 wird gezeichnet.

Neben der Originalkurve bestehend aus 6 Punkten, ist die neu entstandene Kurve, die

nur noch aus 4 Punkten besteht, abgebildet. Betrachtet man die Charakteristik der Kurve

des in Abbildung 3-6 abgebildeten Bereiches, so ist zu vermuten, dass mit Hilfe dieses

Algorithmus eine gute Glättung bzw. Ausdünnung der Kurve erreicht werden kann.

Anhand von verschieden Toleranzwerten d, wurde getestet, inwieweit sich der

Kurvenverlauf verändert. Die drei folgenden Abbildungen zeigen die Beispielkurve

(Kapitel 3.3.1) für verschiedene Toleranzwerte.

Abbildung 3-12 Original Kurve besteht aus 40.000 Punkte

34


Abbildung 3-13 Kurve mit Toleranz 1.0 besteht aus 429 Punkten

Abbildung 3-14 Kurve mit Toleranz 3.0 besteht aus 141 Punkten

Wie man aus Abbildung 3-12 bis Abbildung 3-14 entnehmen kann, bleibt mit

steigendem Toleranzwert die Grundform der Kurve erhalten. Dabei reduzieren sich aber

die zur Darstellung benötigen Punkte extrem. Während die Originalkurve noch 40.000

Messwerte beinhaltet, sind bei einem Toleranzwert von 1.0 lediglich 429 Punkte zur

Darstellung notwendig. Bei einem höheren Toleranzwert von 3.0 reduziert sich die

anzuzeigende Punktmenge sogar auf 141 Punkte.

35


Diese starke Reduzierung der anzuzeigenden Punkte der Kurve hat einen hohen

Geschwindigkeitszuwachs bei der Visualisierung zur Folge, da je nach gewählter

Toleranz nur noch sehr wenige Punkte gezeichnet werden müssen. Mit Hilfe dieser

Darstellung ist zwar keine genaue Auswertung einzelner Punkte möglich, aber man

kann sich einen Gesamtüberblick über den Kurvenverlauf verschaffen und eventuell

interessante Bereiche auswählen und genauer untersuchen. Eine Möglichkeit dazu wäre,

in die Kurve hineinzuzoomen und einen Teilbereich mit höchster Genauigkeit

darzustellen. Eine Analyse der Punkte innerhalb der Gesamtansicht ist ohnehin nicht

effektiv möglich, da bei der Darstellung aller 40.000 Messwerte mehrere Punkte

innerhalb eines Bildschirmpixels liegen und nicht lokalisierbar sind. Dieses Problem ist

in Abbildung 3-12 Seite34 erkennbar.

Aufgrund der Tatsache, dass durch diesen Algorithmus eine sehr starke Reduzierung

der Punktmenge erreicht wurde, wird bei der Erstellung der im nächsten Kapitel

beschriebenen Java-Applikation diese Methode umgesetzt.

36


3.4 Synchronisation der Prüfdateien

In dem neuen Datenbankmodell ist die Möglichkeit vorgesehen einem Versuch mehrere

Messreihen zuzuordnen. Diese Messreihen kommen von verschieden Sensoren am

Prüfstand. Bedingt durch den Aufbau des Prüfvorgangs haben die Messreihen einen

gewissen Zeitversatz, d. h. die Aufzeichnung der Messdaten innerhalb der Prüfdatei 1

ist zeitversetzt zu der Aufzeichnung der Messdaten in der Prüfdatei 2. Beide Messreihen

starten mit dem Zeitwert null. Zum besseren Verständnis dieses Problems wird

beispielhaft ein Schubversuch an einem Lagerpaar herangezogen. Zu diesem Versuch

existieren 2 Messreihen. Zum einen eine vertikale, welche aus einer Druckbelastung

hervorgeht und zum anderen eine horizontale, welche aus der Schubbelastung

hervorgeht. Tabelle 3 zeigt ein mögliches Aussehen der Messreihen.

Messreihe 1 vertikal

Start Aufzeichnung: 15:30:45 Uhr

Messreihe 2 horizontal

Start Aufzeichnung: 15:30:50 Uhr

Zeit [s] Kraft [kN] Weg [mm] Zeit [s] Kraft [kN] Weg [mm]

0 0 0 0 0 0

1 0 0 0,25 10 1

2 100 1 0,5 20 2

3 200 2 0,75 30 3

... ... ... ... ... ...

... ... ... ... ... ...

20 0 0 4,47 5 1

- - - 5 -5 0

Tabelle 3 Mögliches Aussehen von Messreihen

Die beiden Messreihen haben eine Zeitdifferenz von 5 Sekunden. Möchte man jetzt den

Weg der Messreihe 1 über den Weg der Messreihe 2 darstellen, müssen beide

Messreihen zunächst über die Zeit synchronisiert werden. Da zu den Zeitwerten der

Messreihe 1 keine passenden Zeitwerte der Messreihe 2 vorhanden sind, muss zwischen

37


zwei bestehenden Zeitwerten der Messreihe 2 interpoliert werden. Dazu wird ein

lineares Interpolationsverfahren verwendet.

3.5 Speicherung der Prüfdateien

In der bestehenden Access-Client-Applikation werden die Prüfdaten extern (wie unter

Kapitel 2.2 beschrieben) in einem Binärformat gespeichert, das nur mit der bestehenden

Visual-Basic-Applikation wiederhergestellt werden kann. Durch das unleserliche

Binärformat ist kein Einblick mehr in die originale Prüfdatei möglich. Das ist

nachteilig, wenn man bedenkt man, dass eventuell weitere Applikationen entwickelt

werden könnten, für die ein Zugriff auf die originalen Prüfdaten eines Versuches

notwendig werden könnte. Aus diesen Überlegungen heraus wurde die Speicherung der

originalen Prüfdatei, die in Textform vorliegt, realisiert. Ein weiteres Argument für die

binäre Speicherung der Prüfdaten, war der stark reduzierte Speicherplatzbedarf der

erzeugten Binärdatei im Gegensatz zu der originalen Prüfdatei. Um dieses Argument zu

entkräften, wird die Prüfdatei mit allgemein üblichen Kompressionsalgorithmen

komprimiert. In der später beschriebenen Java-Applikation wird auf das GZIP-Format

(Kapitel 3.5.1) für die Kompression zurückgegriffen. Damit bleibt die Möglichkeit

erhalten, auf die originale Prüfdatei zugreifen zu können. Das ermöglicht es wiederum

anderen Applikationen diese Datei zu lesen und die Prüfdaten innerhalb dieser Datei

auszuwerten. Durch das verwendete GZIP-Format wird die Größe der Datei auf ca.

20% reduziert, was als ausreichend betrachtet werden kann. Die Visual-Basic-

Anwendung reduziert die Größe der Originaldatei durch das Binärformat auf ca. 35%.

Ein weiterer Nachteil des Binärformates ist es, dass es bei Beschädigung nicht repariert

werden kann und somit die Daten verloren sind. Im Gegensatz dazu sind eventuell

defekte Archive widerherstellbar und man kann zumindest einen Teil der Daten retten.

Aus den genannten Gründen wird die Speicherung in Textform und Komprimierung

mittels GZIP, der binären Speicherung der Prüfdatei vorgezogen.

38


3.5.1 GZIP Kompressionsformat

GZIP ist ein Kompressionsformat, das von Jean-Loup Gailly entwickelt wurde. Es ist

auf fast allen Betriebssystemen frei verfügbar. Es ist frei von patentierten Algorithmen

und bietet eine gute Kompression. Viele Kompressionsprogramme unterstützen dieses

Format. Als Beispiel sei hier auf das frei erhältliche 7-Zip Programm (www.7-zip.org)

verwiesen. GZIP ist nicht zu verwechseln mit dem ZIP Format unter Windows, das

einen anderen kostenpflichtigen Komprimieralgorithmus verwendet.

Java bietet in seinem aktuellen JDK (Java Development Kit) komfortable Klassen zur

Behandlung des GZIP Formats an.

39

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Implementierung

4 Implementierung

4.1 Auswahl der Technologien

4.1.1 MS-Access

Das Datenbankschema wurde mittels MS-Access umgesetzt. MS-Access ist vollständig

kompatibel zu dem SQL92-Standard, und es ist möglich, mit einem breiten Spektrum

von Programmiersprachen über die von Microsoft bereitgestellte ODBC-Schnittstelle

(Kapitel 3.2.4) auf dieses DBMS zuzugreifen. Diese Kriterien erfüllen auch andere

relationale DBMS, wie mySQL oder Oracle und es wäre durchaus möglich die

Datenbank in diesen DBMS zu implementieren. Die Wahl fiel auf MS-Access, weil

dieses System am Verkehrsbaulehrstuhl zum Einsatz kommt.

4.1.2 Java

Die Wahl der Programmiersprache für die Clientanwendung fiel auf JAVA von SUN

Microsystems. Als neue und moderne Programmiersprache bietet sie dem Anwender

einige Vorteile. Zu nennen ist hierbei die Objektorientierung der Sprache sowie die

eigenständige Verwaltung des Hauptspeichers durch den Garbage-Collector. Dieser

verwaltet den Speicher der in Java benutzten Objekte. Er fungiert quasi als eine Art

„automatischer Mülleimer“. Er stellt zur Laufzeit eines Programms fest, welche

Objekte nicht mehr benötigt werden und gibt deren Speicherplatz frei. Diese Aufgabe

muss in anderen Sprachen vom Programmierer gelöst werden, wobei sehr häufig

Fehlerquellen entstehen.

Ein weiterer Aspekt ist die einfache Möglichkeit mit Hilfe der JDBC-API (Kapitel

4.3.3) von Java, auf relationale Datenbanken zugreifen zu können.

40


4.2 Versuchsdatenbank

In einem ersten Schritt wurden nach dem in Abbildung 3-4 auf Seite 21 gezeigtem ER-

Modell für die jeweiligen Entitäten Tabellen entworfen. Diese Entitäten bzw. Tabellen

wurden mit Attributen versehen, welche die Entitäten beschreiben. So hat

beispielsweise die Entität PRUEFER mehrere verschieden Attribute. Ein sehr wichtiges

Attribut einer Tabelle ist der Primärschlüssel. Dieses Attribut dient der eindeutigen

Identifikation eines Datensatzes innerhalb einer Tabelle. Der Begriff Datensatz

bezeichnet eine Zeile innerhalb einer Tabelle. Eine Tabelle kann beliebig viele

Datensätze beinhalten. Der Primärschlüssel kann innerhalb der Tabelle festgelegt

werden oder von dem benutzten DBMS automatisch erzeugt werden. In den meisten

Fällen handelt es sich um einen Zähler, welcher sich pro Datensatz um eins erhöht.

Bei der Implementierung der Versuchsdatenbank mittels MS-Access, wurde zu jeder

Tabelle solch ein Primärschlüssel definiert, der automatisch für jeden Datensatz einen

eindeutigen Index erzeugt. Neben dem Begriff des Primärschlüssels, gibt es noch den

Begriff des Fremdschlüssels. Ein Fremdschlüssel einer Tabelle verweist auf einen

Primärschlüssel einer anderen Tabelle. Er wird benötigt um die unter Kapitel 3.2.1

aufgeführten Beziehungstypen zwischen den einzelnen Tabellen innerhalb von

rationalen Datenbanken zu realisieren. Abbildung 4-1 auf Seite 42 zeigt eine Übersicht

über die Tabellen inklusive der zugehörigen Attribute, die innerhalb der

Versuchsdatenbank angelegt wurden. Die Primärschlüssel der Tabellen sind dabei mit

PK, die Fremdschlüssel mit FK gekennzeichnet.

41


Abbildung 4-1 Datenbankschema nach ER Modell

Die Beziehungen zwischen den Tabellen VERSUCH - PROBEKOERPER, und

VERSUCH - MESSREIHE entsprechen dem Typ N:M (Kapitel 3.2.1). Innerhalb von

relationalen DBMS werden solche Beziehungen mittels Relationstabellen abgebildet.

Relationstabellen sind Verknüpfungstabellen, deren Felder sich auf andere Tabellen

beziehen. Beispielsweise enthält die Tabelle VERSUCH_MESSREIHE_REL zwei

Felder, zum einen ein Feld zur Aufnahme des Primärschlüssels der Tabelle VERSUCH,

und zum anderen ein Feld für den Primärschlüssel der Tabelle MESSREIHE. Beide

Felder sind innerhalb der Verknüpfungstabelle als Fremdschlüssel deklariert. Mit Hilfe

dieser Verknüpfungs- oder auch Zuordnungstabelle genannt, ist man in der Lage einem

Versuch beliebig viele Messreihen zuzuordnen. Die Beziehung zwischen den Tabellen

VERSUCH - PROBEKOERPER ist auf die gleiche Art und Weise abgebildet. Ein

weiterer Beziehungstyp wird mittels der 1:N Beziehung beschrieben. Dabei wird in der

Tabelle auf der N-Seite der Beziehung ein zusätzliches Attribut zur Aufnahme des

42


Primärschlüssels der Tabelle auf der 1-Seite zugeordnet. Innerhalb der

Versuchsdatenbank findet man diesen Beziehungstyp zwischen den Tabellen

PRUEFER (1) und VERSUCH (N) sowie HERSTELLER (1) und PROBEKOERPER

(N). Abbildung 4-2 soll das Verständnis unterstützen.

Abbildung 4-2 Beziehung1:n

Die neu entworfene Datenbank ist so in der Lage, den Anforderungen zur Speicherung

aller Parameter eines Versuches gerecht zu werden. Jetzt können den Versuchen

beliebig viele Messreihen sowie Probekörper zugeordnet werden. Die Namensgebung

der Attribute der einzelnen Entitäten wurde von der Bedeutung ihres Inhaltes abgeleitet.

43


4.3 Java-Applikation

4.3.1 Funktionsweise

Die entwickelte Java-Applikation beinhaltet mehrere Funktionsbereiche. Abbildung 4-3

soll diese schematisch darstellen.

Abbildung 4-3 Aufgabengebiete der Applikation

Insgesamt sind drei Aufgabengebiete zu erkennen, welche die Java-Applikation

abdecken muss. Die Applikation muss die modifizierte Prüfdatei (Kapitel 3.1) die vom

Prüfstand erzeugt wird einlesen, alle versuchsbeschreibenden Informationen erkennen,

und in die Datenbank schreiben. Die Prüfdaten, die zu visualisieren sind, sollen extern

gespeichert werden. Dazu wird die gesamte Prüfdatei mittels GZIP komprimiert und

außerhalb der Versuchsdatenbank in dem Unterordner \DATEN, der auf derselben

Ebene wie die Datenbank liegt, gespeichert. Innerhalb der Versuchsdatenbank wird in

der Tabelle MESSREIHE in dem Attribut DATEIVERWEIS_EXT, der Verweis auf die

44


dem Versuch zugehörige Messdatei gespeichert. Als weiterer Aufgabenbereich ist das

Einpflegen von Daten unabhängig von der Versuchsaufnahme zu realisieren. Dazu

gehören die Eingabe von Probekörpern und deren Herstellern sowie die Registrierung

von Prüfern, welche die Versuche leiten. Ebenfalls in diesen Bereich fällt die Pflege des

Datenbestandes, was die Aktionen: Löschen, Hinzufügen und Ändern von Datensätzen

beinhaltet. Als letzter Bereich ist die Visualisierung der Daten aufzuzählen. Um die

grafische Darstellung der Versuche zu ermöglichen, muss der Versuch ausgewählt

werden und die zugehörige Prüfdatei, welche die Messdaten enthält, eingelesen werden.

Danach werden die wiederhergestellten Messdaten in Koordinatensystemen grafisch

aufbereitet. Ausgehend von diesen drei Hauptbereichen wird die Java-Applikation

aufgebaut. Für die einzelnen Aufgaben werden Klassen entworfen von denen im

Folgenden einige vorgestellt werden.

4.3.2 Struktur

Unter diesem Punkt wird die Struktur des neuen Viewer-Tools-2.0 vorgestellt. Beim

Aufbau des Viewer-Tools wurden Klassen gleichen Kontextes in Paketen gruppiert.

Ingesamt verfügt das Viewer-Tool-2.0 über drei Pakete, die anschließend kurz

beschrieben werden.

Abbildung 4-4 Struktur des Viewer Tools

Als größter Teil der Applikation sind in dem Paket gui alle Klassen zusammengefasst,

die zur grafischen Darstellung benötigt werden. Es beinhaltet Dialoge zum Einpflegen

der Versuchsdaten in die Datenbank sowie Klassen, welche die grafische Darstellung

45


der Prüfdaten realisieren. In dem Paket tools sind Klassen zusammengefasst, die

Funktionen wie Drucken, Speichern oder das Einlesen der Prüfdateien bereitstellen. Das

Paket db enthält die Funktionalitäten zur Konfiguration und zur Herstellung der

Datenbankverbindung.

4.3.3 Datenbankzugriff

JDBC steht für „Java Database Connectivity“ und ist eine API der Java Plattform. Es

stellt, ähnlich ODBC unter Windows, eine Schnittstelle für den Zugriff auf Datenbanken

dar. Innerhalb der JDBC-API sind Java-Klassen zusammengefasst, die durch ihre

Methoden Funktionalität zum Kommunizieren mit relationalen Datenbanken aus Java-

Applikationen heraus zur Verfügung stellen. Das Aufgabengebiet von JDBC geht dabei

vom Herstellen und Verwalten der Datenbankverbindungen, über das Weiterleiten von

SQL-Abfragen an die Datenbank, bis hin zur Umwandlung der Abfrageergebnisse in

eine für Java nutzbare Form. Das JDBC-Klassenpaket ist von SUN Microsystems

entwickelt worden und wird jeweils mit dem aktuellen JDK mitgeliefert.

Die drei Hauptkomponenten von JDBC sind:

• JDBC – API

Mit JDBC-API wird die Programmierschnittstelle für den Entwickler zum Datenbankzugriff bezeichnet. Innerhalb dieser Schnittstelle wird ausschließlich festgelegt und definiert, durch welche Methoden auf relationale Datenbanken zugegriffen werden kann. Die API wurde komplett mittels Java – Interfaces definiert, welche im Paket java.sql zusammengefasst sind.

• JDBC – Treibermanager

Der JDBC–Treibermanager verwaltet verschiedene JDBC-Treiber zur Laufzeit des Programms. Theoretisch können bei ihm beliebig viele JDBC–Treiber angemeldet werden. Somit ist man in der Lage, innerhalb einer Java-Applikation mit mehreren verschiedenen DBMS zu kommunizieren.

46


• JDBC – Treiber

Die Implementierung der JDBC-API für ein konkretes DBMS bezeichnet man als JDBC-Treiber. Innerhalb dieses Treibers ist der Programmcode implementiert, welcher den Zugriff auf das DBMS regelt. Diese Treiber sind nicht im Standard JDK von Java enthalten.

Gegenwärtig existieren für fast alle DBMS angepasste JDBC–Treiber, die von den

Herstellern oder Drittanbietern zur Verfügung gestellt werden. Tabelle 4 enthält einige

Treiberklassennamen.

DBMS JDBC - Treiberklassenname

MySQL com.mysql.jdbc.Driver

Oracle oracle.jdbc.driver.OracleDriver

IBM DB COM.ibm.db2.jdbc.net.DB2Driver

IDS Server ids.sql.IDSDriver

Tabelle 4 Auswahl von Datenbanktreibern

Aufgrund dessen, dass zum Zeitpunkt der Entwicklung von JDBC nur für sehr wenige

DBMS angepasste JDBC–Treiber zur Verfügung standen, die ODBC-Schnittstelle

jedoch von fast jedem Datenbanksystem unterstützt wurde, definierte SUN einen so

genannten JDBC-ODBC-Brückentreiber (oft auch bezeichnet als JDBC-ODBC-Bridge).

Dieser Treiber setzt auf die ODBC-Schnittstelle von Microsoft auf (Abbildung 4-5 links

Seite 48) und ermöglicht dadurch den Zugriff auf jede beliebige ODBC-Datenquelle.

Dabei übersetzt er JDBC-Befehle in ODBC-Befehle. Mit der Entwicklung dieses

Treibers ermöglichte es SUN, ein breites Spektrum von Datenbanken mittels Java

anzusprechen. Dieser Brücken-Treiber ist Teil des JDK, dass von SUN Microsystems

zur Verfügung gestellt wird.

47


Da die speziell angepassten Treiber für JDBC von den Datenbankherstellern oder von

Drittherstellern kostenpflichtig sind und das verwendetet DBMS MS-Access die

ODBC-Schnittstelle unterstützt, wurde in der vorliegenden Arbeit der JDBC-ODBC-

Brücken-Treiber verwendet. Nachteil dieses Treibers ist die geringere Geschwindigkeit

beim Zugriff auf die Datenbank sowie der geringere Funktionsumfang gegenüber den

speziell auf die DBMS getrimmten Treibern. Die SQL-Grundfunktionalität des JDBC

ODBC-Brücken-Treibers zum Abfragen, Löschen oder Einpflegen von Daten ist

ausreichend. Vorausschauend ergibt sich ein weiterer Vorteil aus der Benutzung dieses

Treibers. Man ist in der Lage, das DBMS, mit dem die Versuchsdatenbank entwickelt

wurde, auszutauschen. Konvertiert man die Datenbank beispielsweise von MS-Access

zu mySQL, kann man mit dem JDBC-ODBC-Brücken-Treiber weiterhin ohne Probleme

auf die mySQL-Datenbank zugreifen, da dieses DBMS ebenfalls die ODBC-

Schnittstelle von Microsoft unterstützt und ODBC-Treiber zur Verfügung stehen.

Anhand des JDBC-ODBC-Brücken-Treibers soll nun aufgezeigt werden wie sich der

Datenbankzugriff mittels Java vollzieht. Abbildung 4-5 zeigt die am Datenbankzugriff

beteiligten Schichten.

Abbildung 4-5 Datenbankzugriff mittels JDBC-ODBC- bzw. JDBC-Oracle-Treiber

48


Für den Datenbankzugriff innerhalb einer Java-Applikation sind grundsätzlich folgende

Schritte auszuführen:

1. Laden des JDBC-Datenbanktreibers

2. Verbindung zur Datenbank über den entsprechenden JDBC-Treiber für das

verwendete DBMS aufbauen (hier MS Access)

3. Erzeugen einer SQL-Anweisung

4. Ausführen der SQL-Anweisung

5. Ergebnis der Anweisung empfangen, wenn der SQL Befehl ein Ergebnis

zurück gibt (SELECT Befehl)

6. Schließen der Datenbankverbindung

Ebenso wie die in Tabelle 4 vorgestellten Treiber, liegt der JDBC–ODBC–Brücken-

Treiber in Form einer Javaklasse vor. Er wird mit der statischen Methode forName()

der Klasse Class geladen. Die Java Syntax für das Laden des JDBC-ODBC-Brücken-

Treibers zeigt Codelisting 1.

Codelisting 1 Laden des JBDC-ODBC-Brücken-Treibers

Ist der Treiber erfolgreich geladen, wird er beim DriverManager von Java registriert.

Wenn die Treiberklasse nicht gefunden wird, wird eine ClassNotFoundException

generiert. Da eine Java-Applikation unter Umständen mit verschiedenen Datenbanken

kommunizieren muss, besteht die Möglichkeit, beim DriverManager mehrere Treiber

anzumelden. Um diese zu verwalten, führt der von JDBC bereitgestellte

DriverManager eine Liste. Jede Art von Zugriffen, die eine Java-Applikation mit

einer Datenbank aufbauen will läuft über den DriverManager. Nach dem Laden des

49


Treibers wird die Verbindung zur Datenbank aufgebaut. Dazu steht innerhalb von Java

ein Connection-Objekt zur Verfügung. Dessen Referenz wird über die Methode

getConnection() der Klasse DriverManager zurück geliefert.

Codelisting 2 Verbindungsaufbau mittels DriverManager

Wie man aus dem Codelisting 2 entnehmen kann, erwartet die Methode üblicherweise

eine URL1 (Uniform Resource Locator), einen Benutzernamen und ein Passwort. Die

URL wird in Form eines Strings übergeben und repräsentiert den vollständigen Pfad zu

der zu öffnenden Datenbankdatei (Datenquelle). Ferner beinhaltet dieser String

(Abbildung 4-6) die Information, um was für ein DBMS es sich handelt, und es wird der

benötigte Treiber geladen.

„jdbc:odbc:DRIVER={Microsoft Access Driver (*.mdb)};DBQ\=E\…Pfadzur Datenbank…\Versuchsdatenbank.mdb“

Abbildung 4-6 URL-Verbindungsstring

Über das Connection-Objekt werden alle Datenbankanfragen und die daraus

resultierenden Ergebnisse abgewickelt. Ist die Verbindung hergestellt, kann über die

Objekte des Typs Statement (einfacher SQL-Befehl), PreparedStatement

(vorkompilierter SQL-Befehl) oder CallableStatement (Aufruf einer Prozedur)

mit der Datenbank kommuniziert werden. In Codelisting 3 werden die Schritte zum

1 Uniform Resource Locator (deutsch „einheitliche Ortsangabe für Ressourcen“) definiert eine Ressource über ihren Zugriffsmechanismus und ihren Ort im Netzwerk

50


Verbindungsaufbau, vom Laden des Treibers bis zum Erhalten des Ergebnisses einer

SQL-Abfrage, in Java- Syntax dargestellt.

Codelisting 3 Übersicht über die Schritte des Datenbankzugriffs

Mit der Methode executeQuery() der Klasse Statement werden die SQL-

Abfragen ausgeführt. Der Rückgabewert dieser Methode ist vom Typ ResultSet. In

diesem ist das Ergebnis der SQL-Abfrage gespeichert. Mittels verschiedener get()

Methoden kann auf das Objekt des Typs ResultSet zugegriffen werden. Im

abgebildeten Codelisting 3 liefert die Methode getString(“NAME“) die Zeichenkette,

die in der Spalte NAME, der Tabelle PRUEFER in der Versuchsdatenbank gespeichert

ist.

Um im Objekt des Typs ResultSet über die Zeilen zu navigieren, existieren

verschiedene Methoden. Diese sind innerhalb der Java Dokumentation ausführlich

beschrieben.

Anzumerken ist, dass die Definition der URL auch mit dem in Windows enthaltenen

Werkzeug ODBC-Datenquellen-Administrator vorgenommen werden kann. Dazu wird

mit Hilfe dieses Werkzeugs ein ODBC-Datenquellenname definiert, der den Pfad zur

Datenbank und den Typ des Datenbanksystems beinhaltet. Beim Verbindungsaufbau

wird dann statt der kompletten URL (Abbildung 4-6 Seite 50), der Name der definierten

Datenquelle angegeben. In der vorliegenden Arbeit wurde auf diese Möglichkeit

51


verzichtet. Es wurde dem Nutzer vielmehr ermöglicht, innerhalb der Java-Applikation

die entsprechenden Parameter zum Zugriff auf die Datenbank einzustellen.

4.3.4 Datenbankverbindung - DbVerbindungsManager.java

Um den unter Kapitel 4.3.3 beschriebenen Datenbankzugriff unter Java innerhalb des

Viewer-Tools-2.0 zu realisieren, wurde die Klasse DbVerbindungsManager.java

aus dem Paket de.uni-weimar.viewer.db implementiert. Diese Klasse stellt die

Verbindung zur Datenbank her. Sie lädt die benötigten Einstellungen, die für den

Verbindungsaufbau notwendig sind aus der Datei „Verbindung.ini“. Innerhalb

dieser Datei wird die URL, der Benutzername und das Passwort sowie der Java -

Klassenname des zu benutzenden Datenbanktreibers gespeichert. Vorteilhaft wirkt sich

dieses Design aus, wenn sich an den Zugriffsparametern etwas ändert. Zum Beispiel

könnte die Versuchsdatenbank an einen anderen Ort verschoben werden. Der Anwender

ist nun in der Lage, durch einfaches Editieren der Datei „Verbindung.ini“ die

nötigen Einstellungen anzupassen, ohne im Quellcode Veränderungen vornehmen zu

müssen. Dazu wird innerhalb des Viewer-Tools-2.0 ein grafischer Dialog bereitgestellt

(DbVerbindungsDialog.java), über den man die nötigen Angaben komfortabel

einstellen kann.

4.3.5 Einpflegen von Versuchsdaten - DbMaske.java

Um in die einzelnen Entitäten der Versuchsdatenbank Daten eingeben zu können,

wurden im Unterpaket gui.formulare Klassen zusammengefasst, welche die

benötigten Funktionalitäten bereitstellen. Die Vorgehensweise bei der Bedienung der

Datenbank erfordert es, einige Daten unabhängig von der Versuchsaufnahme einpflegen

zu können. Zu diesen Daten gehören Angaben zu den Prüfern der Versuche, zu den

Probekörpern sowie zu den Herstellern der Probekörper. Dazu wurde die Klasse

DbMaske.java implementiert. Die Klasse erzeugt, anhand der Anzahl der Attribute

einer Entität der Versuchsdatenbank, eine grafische Maske zur Dateneingabe. Die

Grundstruktur (Abbildung 4-7) dieser Eingabemaske ist für die verschiedenen Entitäten

52


der Datenbank gleich. Je nach Anzahl der Attribute der zu bearbeitenden Entität wird

im Bereich der Detailansicht die Anzahl der benötigten Felder zur Dateneingabe sowie

deren Beschriftungen von der Klasse automatisch angepasst.

Abbildung 4-7 Datenbankeingabeformular

Im linken Teil des Fensters wird dem Nutzer ein Überblick über die gesamten

Datensätze der betrachteten Entität der Datenbank gegeben. Im rechten Teil werden die

jeweiligen Werte der Attribute zu dem in der Gesamtübersicht markierten Datensatz

angezeigt. Weiterhin ist unterhalb der Gesamtansicht ein Feld angeordnet, das zur

Suche innerhalb der Tabelle der Gesamtübersicht dient. Es fungiert als ein Filter für die

erste Spalte der Tabelle. Wird beispielsweise die Tabelle PRUEFER der

Versuchsdatenbank bearbeitet, wird in der ersten Spalte der Tabelle der

Gesamtübersicht der Name des Prüfers angezeigt. Gibt man nun in dem Filterfeld eine

Zeichenkette ein, werden ausschließlich die Namen derjenigen Prüfer angezeigt, deren

Name mit der gleichen Zeichenkette beginnt.

53


Über den Konstruktor der Klasse DbMaske.java kann die Eingabemaske angepasst

werden. Dazu wird beim Instanzieren der Klasse, der Name der Entität(String

tabelle) der Versuchsdatenbank sowie die Attribute(String spaltenname) die

innerhalb der Gesamtansicht benötigt werden, im Konstruktor übergeben. Der

Konstruktor wird aufgerufen durch:

DbMaske(JFrame frm, String titel, String tabelle, String

spaltennamen)

Durch dieses Design ist es möglich, die Eingabemaske an die verschiedenen Entitäten

der Versuchsdatenbank anzupassen.

Im rechten, unteren Teil der Eingabemaske ist die Funktionalität für das Hinzufügen,

das Löschen und das Ändern von Datensätzen implementiert.

4.3.6 Einlesen der Prüfdatei - DbParser.java

Die in Kapitel 3.1 auf Seite 15 vorgestellte Modifikation der Prüfdatei ermöglicht das

einfache Einlesen des Inhaltes der Prüfdateien. Um diese Funktionalität zur Verfügung

zu stellen, ist innerhalb des Packages tools die Klasse DbParser.java implementiert

worden. Die Klasse kann die modifizierten Prüfdateien einlesen und auswerten. Dazu

wird die Prüfdatei zeilenweise eingelesen und nach den in Tabelle 1 definierten

Schlüsselwörtern durchsucht. Wird eines dieser Schlüsselwörter gefunden, kann die

nachfolgende Information gelesen und zugeordnet werden. Ist die Prüfdatei erfolgreich

eingelesen, stehen die Daten des Versuches der Java-Applikation zur Verfügung. Zu

diesem Zweck stehen zwei Methoden der Klasse DbParser.java zur Verfügung. Zum

einen die Methode parseVD(File pruefdatei), welche die den Versuch

beschreibenden Daten einliest und die Methode parsePD(File pruefdatei),

welche die Prüfdaten zur grafischen Darstellung einliest.

Dazu muss der jeweiligen Methode der Klasse DbParser.java als Parameter der

Dateiname der einzulesenden Prüfdatei mitgegeben werden. Nach dem Einlesen der

Prüfdatei, kann mittels get() Methoden der Klasse auf die eingelesenen Werte

zugegriffen werden.

54


4.3.7 Komponenten der Nutzeroberfläche

Der umfangreichste Teil des Viewer-Tools-2.0 besteht aus der grafischen Oberfläche der

Applikation. Sie stellt dem Anwender über eine Menüleiste sowie eine Toolbar

Funktionalität zur Verfügung. Bei der Anordnung und dem Entwurf der Komponenten

wurden die von Java bereitgestellten Layout- und Containerklassen genutzt und

erweitert. Darüber hinaus wurde ein package aus einer Studienarbeit [3] genutzt, das

ein Objekt in Form eines Koordinatensystems zur grafischen Darstellung bereitstellt.

Im Hauptfenster der Applikation wurde eine SplitPane angeordnet, die wiederum

zwei spezielle Containerobjekte (ViewerCoordinateSystem.java) beinhaltet.

Diese Containerobjekte repräsentieren Koordinatensysteme zur grafischen Darstellung.

Sie wurde mit neuen Eigenschaften versehen, und an die speziellen Anforderungen an

die Auswertung der Prüfdaten angepasst. Nachfolgende Abbildung 4-8 zeigt die

Anordnung der Komponenten im Hauptfenster des Viewer-Tool-2.0.

Abbildung 4-8 Komponentenanordnung im Hauptfenster der Applikation

55


4.3.8 Koordinatensystem - package coordinateSystem

Zur grafischen Aufbereitung der Daten wurde ein Paket genutzt und erweitert, welches

im Rahmen einer früheren Studienarbeit von Stefan, Lobers [3] entstand. Dieses Paket

beinhaltet Klassen, die es ermöglichen Komponenten innerhalb eines

Koordinatensystems in einer immer optimalen Sicht für den Anwender darzustellen. Es

umfasst die sehr aufwendigen Skalierungsvorgänge der grafischen Anzeige, die völlig

vor vom Nutzer verborgen bleiben, d.h. im Hintergrund ablaufen. Für das Viewer-Tool

2.0 wurden einige Klassen aus diesem Paket angepasst. So wurde die Klasse

ViewerCoordianteSystem, von der im Paket coordinateSystem ([3] Kapitel 4.2.4.2)

befindlichen Klasse ValueCoordinatSystem([3] Kapitel 4.2.4.2) abgeleitet, d.h. deren

Funktionalität geerbt. Durch das Interface CoordinateComponent ([3] Kapitel 4.2.4.3)

ist die für die Visualisierung von Objekten innerhalb des Koordinatensystems

notwendige Objektstruktur definiert. Die Objekte werden an das Koordinatensystem

übergeben und zeichnen sich selbst.

Für das Viewer-Tool-2.0 wurden neue Komponenten entwickelt, die dieses Interface

implementieren und damit ohne Probleme auf dem bereitgestellten Koordinatensystem

gezeichnet werden können.

Eine ausführliche Beschreibung der Funktionsweise dieser Klassensammlung ist in der

Studienarbeit „Implementierung eines Programms in Java zur Ermittlung von

charakteristischen Kenngrößen“ von Stefan Lobers [3], im Kapitel 4, unter den

Punkten 4.2.4 – 4.2.4.4 zu finden.

4.3.9 Grafische Darstellung

Bei der Darstellung der Prüfdaten war das größte Problem, die Geschwindigkeit der

grafischen Anzeige in den Griff zu bekommen. Mit der ersten Version des Viewer-Tools

war man zwar in der Lage die Daten komfortabel zu visualisieren, was Art und Weise

der Darstellung betraf, jedoch trat bei größeren Messreihen ein erheblicher

Performanceeinbruch der Applikation auf, bis hin zu deren Unbedienbarkeit. Die

Ursache hierfür liegt darin begründet, dass bei der momentan vorhandenen Version des

Viewer-Tool zum Zeichnen der Kurve eine Vielzahl von Komponenten innerhalb des

56


Koordinatensystems erzeugt wird. Die Kurve besteht also aus sehr vielen

Linienabschnitten. Da das Koordinatensystem die Eigenschaften besitzt sich beim

Hinzufügen von Komponenten selbst neu zu zeichnen und zu skalieren, waren bereits

bei ca. 3.000 Werten die Grenzen des Hardwaresystems ausgelotet.

Ein Versuch zur Lösung dieses Problems wurde in der ersten Version des Viewer Tools

realisiert. Dazu wurde in Abhängigkeit von der Menge der darzustellenden Punkte nur

jeder x-te Punkt gezeichnet. Dadurch erreichte man zwar eine Reduzierung der

Punktmenge und eine damit verbundene Beschleunigung der Darstellung, verlor dabei

aber charakteristische Punkte der Kurve. Das hatte zur Folge, dass die Kurve nur noch

wenig Ähnlichkeit mit dem originalen Kurvenverlauf hatte.

Der erste Unterschied zur vorhandenen Version des Viewer-Tools, liegt in der

Vorgehensweise zur Erzeugung der Komponente zur Darstellung der Kurve. Während

die Kurve in der ersten Version des Tools aus vielen kleinen Komponenten (Linien)

zwischen aufeinander folgenden Punkten erzeugt wurde, besteht die neue

Kurvenkomponente aus einer einzelnen Komponente (GesamtKurve_Comp.java). Das

heißt, die Kurve wird einmal komplett erzeugt und an das Koordinatensystem

übergeben. Dieser Vorgang ist drastisch schneller als das Hinzufügen von mehreren

kleineren Linienabschnitten, da sich das Koordinatensystem nur einmal skalieren und

neu zeichnen muss.

Die Komponente zur Darstellung der Gesamtansicht wird durch die Klasse

GesamtKurve_Comp.java repräsentiert. Sie kann sich durch ihre Methode

drawComponent() selbst zeichnen. Die Punkte zur Darstellung der Kurve bezieht die

Klasse aus einem Objekt des Typs Vector, der alle zu zeichnenden Punkte enthält und

bei der Instanzierung übergeben wird.

Durch diese Veränderung ist die neue Java-Applikation in der Lage deutlich mehr

Punkte darzustellen, ohne einen Performanceeinbruch hervorzurufen. Bei gleich

bleibender Darstellungsgeschwindigkeit können statt bisher ca. 3.000 Punkte, 40.000

Punkte einer Messreihe angezeigt werden.

Der nächste Unterschied zur momentan vorhandenen Lösung ist die Wahl des

Algorithmus zur Punktreduzierung. Zur Anwendung im neuen Viewer-Tool-2.0 kam der

Algorithmus, der als Linienglättung (Kapitel 3.3.3) vorgestellt wurde. Mit dessen Hilfe

57


wurde eine erhebliche Reduzierung der Punktemenge erreicht, die zur Darstellung der

Gesamtübersicht der Kurve notwendig ist. Die Kurve bleibt jedoch in ihrer Grundform

erhalten. Dazu wurden verschiedene Tests mit unterschiedlichen Toleranzwerten

durchgeführt (s. Kapitel 3.3.3). In der neuen Java-Applikation wurde außerdem die

Möglichkeit vorgesehen, die Genauigkeit mit der die Kurve gezeichnet werden soll

einzustellen und je nach Größe der Messreihe anzupassen. Der Algorithmus wurde

innerhalb der Klasse ConfigCoordinateSystem.java in der Methode

zeichneGesamteKurve() umgesetzt.

Dieser Algorithmus wird ausschließlich zum Zeichnen der Gesamtansicht der Kurve

verwendet. Innerhalb der Anwendung werden stets die Originaldaten vorgehalten.

Um es dem Anwender zu ermöglichen einen bestimmten Teilbereich einer Kurve

genauer zu untersuchen, wurde ein weiteres Koordinatensystem unterhalb der

Gesamtdarstellung angeordnet. Innerhalb dessen kann der genaue Verlauf eines

Kurvenbereiches analysiert werden. Dazu wird dem Anwender die Möglichkeit

eingeräumt sich einen beliebigen Kurvenabschnitt auszuwählen. Im Unterschied zur

Gesamtdarstellung fehlt in diesem Koordinatensystem kein Punkt der Kurve. Sie bildet

somit den exakten Kurvenverlauf der Messdaten ab. Dadurch ist eine genaue Analyse

der Kurve in dem Bereich möglich. Der Bereich ist vom Anwender frei wählbar. Dabei

kann er sich an der Gesamtübersicht der Kurve orientieren, die ihm im oberen

Koordinatensystem zu Verfügung gestellt wird. Weiterhin kann er entscheiden ob

zusätzlich zur Liniendarstellung der Kurve noch die einzelnen Punkte angezeigt werden.

Es ist möglich, die Koordinaten der dargestellten Punkte durch anklicken des jeweiligen

Punktes abzufragen. Somit ist der Nutzer in der Lage, sehr große Messreihen zu

visualisieren und spezielle Bereiche genauer zu untersuchen.

4.3.10 Synchronisierung

Wie bereits unter Kapitel 3.4 beschrieben, haben bestimmte Versuche bedingt durch

ihre Charakteristik mehrere Prüfdateien zur Folge. Bei einem Schubversuch existieren

z.B. in der Regel zwei Prüfdateien – eine für die horizontale Belastung und eine für die

vertikale Belastung. Da aus versuchstechnischen Gründen die Messsensoren nicht

58


gleichzeitig gestartet werden können, tritt zwischen den Aufzeichnungen der

Prüfdateien ein gewisser Zeitversatz auf. Der Zeitversatz der Prüfdateien wird beim

Einpflegen des Versuches in die Versuchsdatenbank, der jeweiligen Prüfdatei durch den

Anwender zugeordnet und gespeichert. Die Abtastzeitpunkte der Messsensoren sind

ebenfalls unterschiedlich. Dadurch entstehen unterschiedliche Zeitabstände bei der

Aufzeichnung der Messwerte innerhalb der Prüfdateien. Dadurch wird es notwendig die

Messreihen zu synchronisieren. Wird ein Versuch innerhalb der Java-Applikation zur

grafischen Darstellung ausgewählt, werden die Prüfdateien dekomprimiert und mittels

der Methode parsePD(File pruefdatei) eingelesen. Die Daten der Messreihen

stehen in der Java-Applikation in Form eines Vectorobjektes zur Verfügung. Den

Aufbau zeigt Abbildung 4-9.

Abbildung 4-9 Datenmodell der Messreihen nach Import

Möchte der Anwender eine Wertespalte der Messreihe 1 über eine Wertespalte der

Messreihe 2 darstellen, müssen die Messreihen anhand der Zeitspalte der

Hauptmessreihe synchronisiert werden. Diese Aufgabe übernimmt die Methode

synchronisiere(Vector v) der Klasse CoordinateSystemConfig.java.

59


Die Daten werden ausschließlich synchronisiert, wenn

Spalten aus verschiedenen Messreihen ausgewählt werden,

zum Beispiel wenn der Weg der Nebenmessreihe über die

Zeit der Hauptmessreihe dargestellt werden soll. Zu dem

Zeitwert der Hauptmessreihe (1,0s) ist kein zugehöriger

Wert in der Spalte Weg der Nebenmessreihe vorhanden.

Es muss daher für den Zeitpunkt der Hauptmessreihe (1,0s)

ein Wert der Nebenmessreihe Spalte Weg interpoliert werden (x). Die Interpolation

wird linear vorgenommen und von der Methode:

interpoliere(double x1, double x2, double y1, double y2, double x)

Diese Methode is in der Klasse CoordinateSystemConfig.java umgesetzt. Die

lineare Interpolation ist die einfachste Form der Interpolation und geht von einer

Geraden zwischen den Eingangswerten aus.

f ( )x = y1 +((yx2

2

−−

xy

1

1

))∗ (x − x1 ) (7)

Sollen Spalten aus ein und derselben Messreihe dargestellt werden, wird auf die

Originalwerte innerhalb der Messreihe zurückgegriffen, und die Interpolation kann

entfallen.

4.3.11 Speicherung/Archivierung

Um die Speicherung der Prüfdateien umzusetzen, wurde auf die von Java bereitgestellte

GZIP-Funktionalität zurückgegriffen. Damit kein Dateiname doppelt vergeben werden

kann, wurde ein eindeutiger Name für die gespeicherte Prüfdatei erzeugt. Der Name

wird nach folgendem Schema gewählt:

Beispieldateiname : v348mr430testCR60.gz

60


Abbildung 4-10 Namenszusammensetzung der gespeicherten Prüfdatei

Innerhalb des gepackten Archivs liegt die originale modifizierte Prüfdatei in Textform

vor und kann nach dem Wiederherstellen des Archivs mit einem herkömmlichen

Texteditor gelesen werden. Die Prüfdateien können dadurch nach ihrer Speicherung

weiterhin von Drittanwendungen gelesen werden. Sie sind somit nicht mehr abhängig

von der Anwendung mit der sie gespeichert wurden, wie es bei der vorhandenen Visual-

Basic-Applikation der Fall ist.

Selbst bei Verlust der Datenbank wäre man in der Lage, anhand der Dateinamen zu

rekonstruieren, welche Messreihen einem Versuch zugeordnet waren. Da die

Prüfdateien in Originalform gespeichert sind und die versuchsbeschreibenden Daten

teilweise innerhalb dieser Dateien enthalten sind, hat man durch diese Art der

Speicherung neben der Datenbank eine zusätzliche Sicherung gegen Datenverlust.

61

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Zusammenfassung

5 Zusammenfassung

Mit der vorliegenden Arbeit ist der Versuch unternommen worden, eine Lösung zu

erarbeiten, die es ermöglicht die verschiedenenartigen Versuchsdurchführungen zu

verwalten und zu archivieren sowie die anfallenden Prüfdaten zu visualisieren.

Insbesondere die Visualisierung der Prüfdaten ist ein erheblicher Bestandteil bei der

Auswertung der Versuche und unerlässlich für die zuverlässige Analyse der

Probekörper. In diesem Zusammenhang wurden mehrere Teilbereiche bearbeitet.

Das Format der vom Prüfstand erzeugten Prüfdatei wurde optimiert, um ein

automatisiertes Verarbeiten der Daten zu ermöglichen. Innerhalb der Prüfdateien wurde

jede den Versuch beschreibende Information durch neu eingeführte Schlüsselwörter

eindeutig gekennzeichnet. Durch das Hinzufügen dieser zusätzlichen Informationsebene

entstand eine neue Struktur der Prüfdatei. Dadurch ist eine wesentlich effizientere

Weiterverarbeitung z.B. durch Computerprogramme möglich.

Der Entwurf der Versuchsdatenbank für die Verwaltung und Archivierung der Versuche

wurde mit dem DBMS MS-Access implementiert. Das vorgestellte Konzept der

Datenbank ist jedoch mit jedem relationalen DBMS umsetzbar. Mit der entstandenen

Versuchsdatenbank können alle Parameter der verschiedenen Versuchstypen

aufzunehmen und abzuspeichern.

Die Prüfdateien der Versuche sind nicht innerhalb der Datenbank abgelegt. Sie werden

außerhalb der Datenbank mittels GZIP komprimiert und abgespeichert. In der

Datenbank wird nur der Verweis zu den Prüfdateien abgelegt. Durch diese Art der

Archivierung bleibt die originale Prüfdatei erhalten und kann bei Bedarf von

Drittanwendungen gelesen werden.

Eine Client-Software zur Bedienung der Datenbank wurde mittels Java umgesetzt. Sie

stellt dem Nutzer eine grafische Oberfläche für die Bedienung der Datenbank sowie zur

Visualisierung der Prüfdaten zur Verfügung. Sie ist in der Lage, die modifizierten

Prüfdateien einzulesen und in der Datenbank abzuspeichern. Ferner wurden

Funktionalitäten implementiert, die es ermöglichen die Prüfdaten zu visualisieren. Dazu

wird dem Nutzer eine Gesamtansicht sowie eine Bereichsansicht des aus den Prüfdaten

resultierenden Kurvenverlaufes zur Verfügung gestellt.

62

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Zusammenfassung

Trotz der Effizienz der entwickelten Java-Applikation bleibt kritisch anzumerken, dass

zur Erhöhung der Komfortabilität für den Nutzer weitere Funktionalitäten ergänzt

werden könnten, so z.B. durch ein komplexes Formular für die Suche innerhalb der

Datenbank.

Die Datenbank und die optimierten Prüfdateien bilden die Grundlage für die

Entwicklung von Client-Anwendungen. Bei Kenntnis der Struktur der Datenbank sowie

der Bedeutung der Schlüsselwörter können ohne Schwierigkeiten weitere Programme

zur Bedienung der Datenbank und zum Auswerten der Prüfdateien entwickelt werden,

d.h. das Lösungskonzept ist nicht zwingend an die Programmiersprache Java gebunden.

63

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Bedienungsanleitung

6 Bedienungsanleitung

6.1 Installation

6.1.1 Systemvoraussetzungen

Zum Ausführen der Viewer-Tool-2.0 Applikation wird eine Installation des Java-

Runtime-Environment 5.0 oder höher für Windows vorausgesetzt. Dieses steht kostenlos

unter http://java.sun.com zum Download bereit. Weiterhin ist ein installierter ODBC-

Access-Treiber erforderlich, der für den Zugriff auf die Versuchsdatenbank benötigt

wird. Dieser ist auf Windowssystemen Bestandteil des Betriebssystems. Eine Anzeige

der installierten ODBC-Treiber unter Windows XP kann mit dem ODBC-

Datenquellenadministrator vorgenommen werden:

Start > Systemsteuerung > Verwaltung > Datenquellen (ODBC).

Mit einem Klick auf die Registerkarte Treiber, bekommt man eine Liste der im System

installierten ODBC-Treiber angezeigt.

Wenn kein geeigneter Treiber installiert sein sollte, kann man das aktuelle MDAC-Paket

(Microsoft Data Access Components) herunterladen und installieren. Die MDAC-Pakete

sind kostenlos und können von der Microsoft-Internetseite unter

http://msdn.microsoft.com/data/mdac/downloads/ bezogen werden. Sie enthalten die

aktuellsten ODBC-Treiber von Microsoft.

6.1.2 Installation

Das Viewer-Tool-2.0 ist auf der Beigelegten CD im Ordner Installation zu finden.

Es wird durch das Ausführen der Datei viewer_windows_2_0.exe auf dem

Computer installiert. Ebenfalls befindet sich die Versuchsdatenbank (versuch.mdb) im

Ordner Datenbank auf der Begleit-CD ROM. Die Versuchsdatenbank muss inklusiver

des Ordners \Daten an eine beliebige Stelle des lokalen Rechners oder auf ein

Netzlaufwerk kopiert werden.

64


6.2 Bedienung

6.2.1 Konfigurieren der Datenbankverbindung

Beim ersten Start des Programms ist es notwendig die Datenbankverbindung zu

konfigurieren. Die nötigen Einstellungen nimmt man im Dialog

Verbindungseinstellungen vor. Diesen erreicht man nach dem Start des Programms,

über das Datei-Menü, unter dem Menüeintrag Einstellungen oder über die Toolbar.

Abbildung 6-1 Verbindungseinstellungsdialog

Der sich öffnende Dialog zeigt im Abschnitt „Java Datenbank Treiber“ den momentan

verwendeten Treiber in Form des vollständigen Klassenpfads an. In dieser Arbeit ist es

der von Sun bereitgestellte JDBC-ODBC-Brücken-Treiber, der für den Zugriff auf

Accessdatenbanken genutzt wird. In der Datenbank URL wird der Pfad zur Datenbank

gespeichert, den man mit dem Button Datenbank auswählen einstellen kann. Weiterhin

sind ein Benutzername und das Passwort für den Zugriff auf die Datenbank anzugeben.

6.2.2 Einpflegen von Daten

Ist die Datenbankverbindung korrekt installiert, kann man unter dem Menüpunkt Daten

einpflegen, die Tabellen der Versuchsdatenbank mit Daten füllen. Dazu stehen drei

Menüpunkte zur Verfügung, welche die jeweiligen Eingabemasken für die

65


Dateneingabe aufrufen. Bei der Prüfereingabe öffnet sich der in Abbildung 6-2 gezeigte

Dialog.

Abbildung 6-2 Dialog zur Eingabe von Prüfern

Auf der linken Seite wird in Form einer Tabelle ein Gesamtüberblick über die Einträge

der Tabelle PRUEFER gegeben. Auf der rechten Seite sind die Detailangaben des

jeweiligen selektierten Eintrags zu sehen. Weiterhin sind im unteren Teil

Funktionselemente zum Hinzufügen, Löschen und Ändern von Daten untergebracht.

Unter der Gesamtansicht befindet sich ein Suchfeld, das als Filter für die Tabelle

fungiert. In Abbildung 6-2 werden innerhalb der Gesamtansicht nur Prüfer deren Name

mit dem Buchstaben “K“ beginnt angezeigt. So kann man diesen Filter weiter

verfeinern, oder das Feld leer lassen, was eine Anzeige von allen Datensätzen zur Folge

hat. Die Eingabemasken zur Aufnahme von Probekörpern sowie deren Hersteller sind

auf dieselbe Art und Weise aufgebaut.

6.2.3 Einlesen einer Prüfdatei

Zum Einpflegen eines Versuches steht unter dem Menü Daten einpflegen der

Menüeintrag Versuch zur Verfügung. Mit Hilfe dieses Dialoges kann eine

Hauptprüfdatei ausgewählt und importiert werden. Als Hauptprüfdatei wird die jeweils

erste eingelesene Prüfdatei bezeichnet. Aus dieser Datei werden die den Versuch

beschreibenden Daten eingelesen. Sind die Daten eingelesen, so hat der Nutzer die

66


Möglichkeit Änderungen sowie Ergänzungen an den eingelesenen Daten vorzunehmen.

Ebenso besteht die Möglichkeit, weitere Prüfdateien dem Versuch zuzuordnen.

Abbildung 6-3 Dialog zum Einpflegen von Versuchen

Mit den Schaltflächen Ok oder übernehmen werden die Versuchsdaten in die

Datenbank geschrieben und die Prüfdateien außerhalb der Datenbank im Ordner

/Daten komprimiert und gespeichert.

6.2.4 Grafische Darstellung

Zur grafischen Anzeige der Prüfdaten sind zwei Koordinatensysteme innerhalb des

Hauptfensters angeordnet worden. Im oberen System wird die Gesamtansicht der Kurve

zur Verfügung gestellt und im unteren ein Teilbereich der Kurve, der beliebig

ausgewählt werden kann. Zuvor muss man über das Menü Grafische Darstellung

und den Menüeintrag Versuch auswählen einen Versuch zur grafischen Darstellung

auswählen. Nach dem Einlesen der Prüfdaten des Versuches öffnet sich ein

67


Konfigurationsfenster mit dessen Hilfe der Anwender in der Lage ist, die Art und Weise

der Darstellung anzupassen.

Abbildung 6-4 Grafische Nutzeroberfläche für die Visualisierung

Das Fenster zur Konfiguration der grafischen Anzeige gliedert sich in drei Bereiche. Im

oberen Teilbereich werden Angaben zu dem Versuch angezeigt, um dem Anwender

einen Überblick zu verschaffen um welchen Versuch es sich handelt.

Im mittleren Bereich wird die Darstellung der Gesamtkurve eingestellt. Man kann die

Koordinatenachsen mit beliebigen Wertereihen belegen sowie die Genauigkeit der

angezeigten Kurve beeinflussen. Dazu wird mit dem Schieberegler Genauigkeit der

Wert der Abweichung bestimmt. Bei einem Wert von null werden alle Punkte der

Kurve gezeichnet. Je größer der Wert eingestellt wird umso ungenauer wird der

Kurvenverlauf, da die Kurve aus immer weniger Punkten besteht. (Der angezeigte Wert

ist der Toleranzwert des Abstandes in Einheiten) Der Wert Bei sehr großen Messreihen

kann so die Geschwindigkeit der Darstellung angepasst werden. Mit dem aktivieren der

Checkbox kann man sich innerhalb des oberen Koordinatensystems die Angaben zum

Versuch einblenden lassen.

68


Der untere Bereich des Konfigurationsfensters ist zum Einstellen des Teilbereiches der

Kurve vorgesehen. Hier ist man ebenfalls in der Lage die Koordinatenachsen beliebig

zu belegen. Des Weiteren kann man einen Zeitbereichbereich angeben, für den der

genaue Kurvenverlauf angezeigt wird. Wenn der gewünschte Zeitbereich eingestellt ist,

kann man mit dem Schiebregler die gesamte Kurve abfahren. Wird ein neuer Bereich

eingestellt aktualisiert sich der Schieberegler automatisch und springt an die

Anfangsposition des angegebenen Bereiches. Weiterhin kann im unteren

Koordinatensystem zusätzlich die Punktdarstellung der Kurve aktiviert werden. Ist die

Punktdarstellung aktiv können durch Anklicken der einzelnen Punkte die Wertepaare

dieser abgefragt werden.

6.2.5 Drucken und Speichern

Nachdem das Viewer-Tool-2.0 an die Bedürfnisse des Nutzers angepasst ist, besteht die

Möglichkeit den Bildschirminhalt auszudrucken oder als Grafikdatei abzuspeichern.

Dazu stehen im Menü Datei die Menüeinträge Grafik speichern und drucken zur

Verfügung. Das Viewer-Tool-2.0 kann die Datei als JPEG, BMP oder im PNG Format

speichern. Beim Drucken wird die Größe des Hauptfensters automatisch auf den

bedruckbaren Bereich skaliert.

6.2.6 Layout der Anwendung

Es steht das Windows, Motif - und Metal Look&Feel zur Verfügung. Das Viewer-Tool

startet standardmäßig mit dem System - Look&Feel und passt sich damit dem aktuellen

Profil der Umgebung an. Das Look&Feel kann zur Laufzeit des Programms

umgeschaltet werden. Diese Eigenschaft des Programms ermöglicht es dem Nutzer sich

in seiner gewohnten Systemumgebung zu bewegen. Dazu steht im Menü Datei, unter

dem Menüeintrag Einstellungen der Menüpunkt L&F zur Verfügung.

69

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung 2-1 links: Prüfstand an der Professur Verkehrsbau; rechts Probekörper........ 7

Abbildung 2-2 Skizze zur Versuchsdurchführung............................................................ 8

Abbildung 2-3 Prüfdatei eines Druckversuches ............................................................... 9

Abbildung 2-4 Drucksteuerdatei für einen Druckversuch................................................ 9

Abbildung 3-1 Modifizierte Drucksteuerdatei................................................................ 17

Abbildung 3-2 Neue Prüfdatei ........................................................................................ 18

Abbildung 3-3 Modellierungssyntax des ER-Modells ................................................... 19

Abbildung 3-4 Modellentwurf der Versuchsdatenbank.................................................. 21

Abbildung 3-5 ODBC Treiberstruktur............................................................................ 25

Abbildung 3-6 Kurvencharakteristik .............................................................................. 27

Abbildung 3-7 Kurvencharakteristik 1 ........................................................................... 28

Abbildung 3-8 Anstiegsdifferenz; links P2 wird gezeichnet; rechts P2 wird nicht

gezeichnet ....................................................................................................................... 29

Abbildung 3-9 Punktreduzierung mittels Anstiegsverfahren ......................................... 30

Abbildung 3-10 Pfeilhöhenverfahren allgemein............................................................. 32

Abbildung 3-11 Pfeilhöhenverfahren Beispiel ............................................................... 33

Abbildung 3-12 Original Kurve besteht aus 40000 Punkte........................................... 34

Abbildung 3-13 Kurve mit Toleranz 1.0 besteht aus 429 Punkten................................. 35

Abbildung 3-14 Kurve mit Toleranz 3.0 besteht aus 141 Punkten................................. 35

Abbildung 4-1 Datenbankschema nach ER Modell ....................................................... 42

Abbildung 4-2 Beziehung1:n.......................................................................................... 43

Abbildung 4-3 Aufgabengebiete der Applikation .......................................................... 44

Abbildung 4-4 Struktur des Viewer Tools...................................................................... 45

Abbildung 4-5 Datenbankzugriff mittels JDBC-ODBC- bzw. JDBC-Oracle-Treiber... 48

70

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Abbildungsverzeichnis

Abbildung 4-6 URL-Verbindungsstring........................................................................ 50

Abbildung 4-7 Datenbankeingabeformular .................................................................... 53

Abbildung 4-8 Komponentenanordnung im Hauptfenster der Applikation ................... 55

Abbildung 4-9 Datenmodell der Messreihen nach Import ............................................. 59

Abbildung 4-10 Namenszusammensetzung der gespeicherten Prüfdatei....................... 61

Abbildung 6-1 Verbindungseinstellungsdialog .............................................................. 65

Abbildung 6-2 Dialog zur Eingabe von Prüfern............................................................. 66

Abbildung 6-3 Dialog zum Einpflegen von Versuchen.................................................. 67

Abbildung 6-4 Grafische Nutzeroberfläche für die Visualisierung................................ 68

71

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Codelisting

Codelisting

Codelisting 1 Laden des JBDC-ODBC-Brücken-Treibers ............................................. 49

Codelisting 2 Verbindungsaufbau mittels DriverManager............................................. 50

Codelisting 3 Übersicht über die Schritte des Datenbankzugriffs .................................. 51

72

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 1 Übersicht über die eingeführten Schlüsselwörter ........................................... 16

Tabelle 2 Lesen der Relationen ...................................................................................... 22

Tabelle 3 Mögliches Aussehen von Messreihen............................................................. 37

Tabelle 4 Auswahl von Datenbanktreibern .................................................................... 47

73

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Literaturverzeichnis

Literaturverzeichnis

[1] RIEDEL, THOMAS

“Datenbank zur Verwaltung von Versuchsdaten”

Studienarbeit; Lehrstuhl Informatik im Bauwesen; Professur Verkehrsbau; Bauhaus-Universität Weimar 2004

[2] RIEDEL, THOMAS

“Implementierung einer graphischen Nutzeroberfläche zur Auswertung und Bearbeitung von Versuchsdaten“

Studienarbeit; Lehrstuhl Informatik im Bauwesen; Bauhaus-Universität Weimar 2004

[3] LOBERS, STEFAN

“Implementierung eines Programms in Java zur Ermittlung von charakteristischen Kenngrößen“

Studienarbeit; Lehrstuhl Informatik im Bauwesen; Baushaus-Universität Weimar 2003

[4] GREORGI, SVEN

“Druckstauchungsverhalten bewehrter Elastomerlager“

Diplomarbeit; Professur Verkehrsbau; Bauhaus-Universität Weimar 2005

[5] S. HORSTMANN / GRAY CORNELL

“core JAVA 1 – Grundlagen” ; 1999; Markt&Technik; ISBN 3-8272-9565-3

“core JAVA 2 – Expertenwissen”; 2000; Markt&Technik; ISBN 3-8272-9566-1

[6] ULLENBOOMS, CHRISTIAN: *

"Java ist auch eine Insel" ; Galileo Press; ISBN 3-89842-304-2

http://www.galileocomputing.de/openbook/javainsel4/

74

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Literaturverzeichnis

[7] WIKIPEDIA; Die freie Enzyklopädie

http://de.wikipedia.org

[8] P.S. CHEN

“The Entity-Relationship Model - Toward a Unified View of Data Transactions on Database Systems”

Volume 1, No 1. 1976

75

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Anhang

Anhang

• Begleit CD

- dieses Document im Adobe-Acrobat-Reader Format (.pdf)

- die Versuchsdatenbank im MS-Access Format versuch.mdb

- der Java Quellcode des Viewer-Tool-2.0

- kompilierte class-Dateien des Viewer-Tool-2.0

- Setup-Programm für Windows 32 Plattformen (ermöglicht eine Programmgeführte Installation des Viewer-Tools-2.0)

- Setupprogramm für das Java-Runtime-Environment Version 1_5_0_0_6 (wird zum Ausführen von Java Programmen unter Windows benötigt)

76

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Selbständigkeitserklärung

Selbständigkeitserklärung

Ich erkläre, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der

angegebenen Quellen und Hilfsmittel angefertigt habe.

Weimar, den 23. Dezember 2005

77

Implementierung einer Applikation zur Verwaltung und Auswertung von Prüfdaten Thesen

Thesen

1. Die Speicherung der Prüfdaten in einem allgemeinen Textformat

gewährleistet auch nach Jahren noch die Lesbarkeit der archivierten Daten.

2. Die Kennzeichnung der Informationen innerhalb der Prüfdateien ermöglicht

das automatisierte Erfassen des Inhaltes.

3. Bei der Vielzahl an verschiedenen Versuchen ist eine rechnergestützte

Verwaltung in Form einer Datenbank sinnvoll und komfortabel.

4. Die von MS-Access unterstützte ODBC-Treiber-Schnittstelle ist offen gelegt.

Damit ist ein stabiler Standard für den Zugriff auf die Versuchsdatenbank

sichergestellt.

5. Java bietet mit JDBC eine API zum einfachen Zugriff auf Datenbanken.

Durch den standardmäßig mitgelieferten JDBC-ODBC-Brücken-Treiber

werden keine weiteren eventuell kostenpflichtigen Komponenten für den

Zugriff auf MS-Access Datenbanken benötigt.

6. Die Visualisierung der Prüfdaten ist für eine effektive Analyse der

Probekörper sehr wichtig.

7. Die Gesamtübersicht über eine aus den Prüfdaten erzeugten Kurve ist für die

Auswertung ebenso von Bedeutung wie die Darstellung eines

Kurvenbereiches.

78

Documents

DA Riedel Version Finishopenifctools.com/homepage_s/uni/DA_Riedel.pdf · Bauhaus-Universität Weimar Fakultät Bauingenieurwesen Lehrstuhl Informatik im Bauwesen DIPLOMARBEIT IMPLEMENTIERUNG